Reducing SPI flash frequency allows the build to boot on both old variants
with W25Q128 chip and new variants with XM25QH128C chip.
The old 80000000 value only boots on devices with the W25Q128 flash.
This is also the change Cudy themselves made in their openwrt builds and
their .dts file.
Removed m25p,fast-read as it is not needed with slower speeds.
Signed-off-by: Filip Milivojevic <zekica@gmail.com>
Light and small router ( In Poland operators sells together with MC7010 outdoor modem to provide WIFI inside home).
Device specification
SoC Type: Qualcomm IPQ4019
RAM: 256 MiB
Flash: 128 MiB SPI NAND (Winbond W25N01GV)
ROM: 2MiB SPI Flash (GD25Q16)
Wireless 2.4 GHz (IP4019): b/g/n, 2x2
Wireless 5 GHz (QCA9982): a/n/ac, 3x3
Ethernet: 2xGbE (WAN/LAN1, LAN2)
USB ports: No
Button: 2 (Reset/WPS)
LEDs: 3 external leds: Power (blue) , WiFI (blue and red), SMARTHOME (blue and red) and 1 internal (blue) -- NOTE: Power controls all external led (if down ,all others also not lights even signal is up)
Power: 5VDC, 2,1A via USB-C socket
Bootloader: U-Boot
On board ZWave and Zigbee (EFR32 MG1P232GG..) modules ( not supported by orginal software )
Installation
1.Open MF18A case by ungluing rubber pad under the router and unscrew screws, and connect to serial console port,
with the following pinout, starting from pin 1, which is the topmost pin when the board is upright (reset button on the bottom) :
VCC (3.3V). Do not use unless you need to source power for the converer from it.
TX
RX
GND
Default port configuration in U-boot as well as in stock firmware is 115200-8-N-1.
2.Place OpenWrt initramfs image for the device on a TFTP in the server's root. This example uses Server IP: 192.168.0.2
3.Connect TFTP server to RJ-45 port (WAN/LAN1).
4.Power on MF18A , stop in u-Boot (using ESC button) and run u-Boot commands:
setenv serverip 192.168.0.2
setenv ipaddr 192.168.0.1
set fdt_high 0x85000000
tftpboot 0x84000000 openwrt-ipq40xx-generic-zte_mf18a-initramfs-fit-zImage.itb
bootm 0x84000000
5.Please make backup of original partitions, if you think about revert to stock, specially mtd8 (Web UI) and mtd9 (rootFS). Use /tmp as temporary storage and do:
WEB PARITION
cat /dev/mtd8 > /tmp/mtd8.bin
scp /tmp/mtd8.bin root@YOURSERVERIP:/
rm /tmp/mtd8.bin
ROOT PARITION
cat /dev/mtd9 > /tmp/mtd9.bin
scp /tmp/mtd9.bin root@YOURSERVERIP:/
rm /tmp/mtd9.bin
If you are sure ,that you want to flash openwrt, from uBoot, before bootm, clean rootfs partition with command:
nand erase 0x1800000 0x1D00000
6.Login via ssh or serial and remove stock partitions (default IP 192.168.1.1):
ubiattach -m 9 # it could return error if ubi was attached before or rootfs part was erased before
ubirmvol /dev/ubi0 -N ubi_rootfs # it could return error if rootfs part was erased before
ubirmvol /dev/ubi0 -N ubi_rootfs_data # some devices doesn't have it
7. Install image via :
sysupgrade -n /tmp/openwrt-ipq40xx-generic-zte_mf18a-squashfs-sysupgrade.bin
previously wgeting bin. Sometimes it could print ubi attach error, but please ignore it if process goes forward.
Back to Stock (!!! need original dump taken from initramfs !!!) -------------
Place mtd8.bin and mtd9.bin initramfs image for the device on a TFTP in the server's root. This example uses Server IP: 192.168.0.2
Connect serial console (115200,8n1) to serial console connector .
Connect TFTP server to RJ-45 port (WAN/LAN1).
rename mtd8.bin to web.img and mtd9.bin to root_uImage_s
Stop in u-Boot (using ESC button) and run u-Boot commands:
This will erase Web and RootFS:
nand erase 0x1000000 0x800000
nand erase 0x1800000 0x1D00000
This will restore RootFS:
tftpboot 0x84000000 root_uImage_s
nand erase 0x1800000 0x1D00000
nand write 0x84000000 0x1800000 0x1D00000
This will restore Web Interface:
tftpboot 0x84000000 web.img
nand erase 0x1000000 0x800000
nand write 0x84000000 0x1000000 0x800000
After first boot on stock firwmare, do a factory reset. Push reset button for 5 seconds so all parameters will be reverted to the one printed on label on bottom of the router
As reference was taken MF289F support by Giammarco Marzano stich86@gmail.com and MF286D by Pawel Dembicki paweldembicki@gmail.com
Signed-off-by: Marcin Gajda <mgajda@o2.pl>
glinet forum users reported the problem at
https://forum.gl-inet.com/t/gl-ar300m16-openwrt-22-03-0-rc5-usb-port-power-off-by-default/23199
The current code uses the regulator framework to control the USB power
supply. Although usb0 described in DTS refers to the regulator by
vbus-supply, but there is no code related to regulator implemented
in the USB driver of QCA953X, so the USB of the device cannot work.
Under the regulator framework, adding the regulator-always-on attribute
fixes this problem, but it means that USB power will not be able to be
turned off. Since we need to control the USB power supply in user space,
I didn't find any other better way under the regulator framework of Linux,
so I directly export gpio.
Signed-off-by: Luo Chongjun <luochongjun@gl-inet.com>
Add support for D-Link DIR-1935 A1 based on similarities to DIR-882 A1,
DIR-867 A1 and other DIR-8xx A1 models. Existing DIR-882 A1 openwrt
"factory" firmware installs without modificaitons via the D-Link
Recovery GUI and has no known incompatibilities with the DIR-1935 A1.
Changes to be committed:
new file: target/linux/ramips/dts/mt7621_dlink_dir-1935-a1.dts
modified: target/linux/ramips/image/mt7621.mk
modified: target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
Specifications:
* Board: Not known
* SoC: MediaTek MT7621 Family
* RAM: 128 MB (DDR3)
* Flash: 16 MB (SPI NOR)
* WiFi: MediaTek MT7615 Family (x2)
* Switch: 1 WAN, 4 LAN (Gigabit)
* Ports: 1 USB 3.0
* Buttons: Reset, WiFi Toggle, WPS
* LEDs: Power (green/orange), Internet (green/orange), WiFi 2.4G (green),
WiFi 5G (green)
Notes:
* 160MHz 5GHz is available in LuCi but does not appear to work (i.e. no
SSID is visible in wifi scanning apps on other devices) with either
official DIR-882 A1 firmware or a test build for the DIR-1935 A1 based
on the 22.03.2 branch. 80 MHz 5GHz works.
Serial port:
* Untested (potential user damage/error)
* Expected to be identical to other DIR-8xx A1 models:
* Parameters: 57600, 8N1
* Location: J1 header (close to the Reset, WiFi and WPS buttons)
* Pinout: 1 - VCC
2 - RXD
3 - TXD
4 - GND
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
Signed-off-by: Keith Harrison <keithh@protonmail.com>
The Asus RT-AX1800U is identical to the already supported Asus RT-AX53U.
Use the ALT0 buildroot tags to show both devices.
Tested-by: Marian Sarcinschi <znevna@gmail.com>
Signed-off-by: Felix Baumann <felix.bau@gmx.de>
This device is a 'Range extender' variant of the Xiaomi 4A router.
Its identical to the 100m non-intl/chinese version as much as it can run
the same firmware, differences being form factor, LEDs, WPS button
and one 100M port only.
The stock firmware differs significantly, being 'app managed only'.
Device specification
--------------------
SoC: MT7628DAN MIPS_24KEc@580MHz 2.4G-n 2x2
WiFi: MT7612EN 5G-ac 80MHz 2T2R
Flash: 16MB W25Q128BV
DRAM: 64MB built-in SoC
Switch: built-in SoC
Ethernet: 1x10/100 Mbps
USB: None
Antennas: 2 x external, non-detachable
LEDs: 2 programmable blue/amber
Buttons: WPS and reset (hidden)
Housing: Range Extender / Wall wart
Serial: 115200,8n1
MAC Addresses
-------------
All 3 MACs are read from flash and identical to stock.
Label MAC is WIFI 2G
Installation
------------
No HTML UI on this device, serial console only. The serial connector
is unpopulated but standard size and clearly marked. Flash from the
U-Boot shell at boot by choosing (2) and flashing the sysupgrade file
via tftp.
Recovery/Debricking procedures of the xiaomi 4A and variants should
work, but there currently is no official source for the stock firmware.
Signed-off-by: Jo Deisenhofer <jo.deisenhofer@gmail.com>
Prepare for a new target with different led definitions that wants to
include this dtsi. The resulting dtb are unchanged, verified with dtdiff
Signed-off-by: Jo Deisenhofer <jo.deisenhofer@gmail.com>
This adds basic support for TP-Link EC330-G5u Ver:1.0 router (also known
as TP-Link Archer C9ERT).
Device specification
--------------------
SoC Type: MediaTek MT7621AT
RAM: 128 MiB, Nanya NT5CC64M16GP-DI
Flash: 128 MiB NAND, ESMT F59L1G81MA-25T
Wireless 2.4 GHz (MediaTek MT7615N): b/g/n, 4x4
Wireless 5 GHz (MediaTek MT7615N): a/n/ac, 4x4
Ethernet: 5xGbE (WAN, LAN1, LAN2, LAN3, LAN4)
USB ports: 1xUSB3.0
Button: 4 (Led, WiFi On/Off, Reset, WPS)
LEDs: 7 blue LEDs, 1 orange(amber) LED, 1 white(non-gpio) LED
Power: 12 VDC, 2 A
Connector type: Barrel
Bootloader: First U-Boot (1.1.3), Main U-Boot (1.1.3). Additionally,
original TP-Link firmware contains Image U-Boot (1.1.3).
Serial console (UART)
---------------------
V
+-------+-------+-------+-------+
| +3.3V | GND | TX | RX |
+---+---+-------+-------+-------+
| J2
|
+--- Don't connect
Installation
------------
1. Rename OpenWrt initramfs image to test.bin and place it on tftp server
with IP 192.168.0.5
2. Attach UART, switch on the router and interrupt the boot process by
pressing 't'
3. Load and run OpenWrt initramfs image:
tftpboot
bootm
4. Once inside OpenWrt, switch to the first boot image:
fw_setenv BootImage 0
5. Run 'sysupgrade -n' with the sysupgrade OpenWrt image
Back to Stock
-------------
1. Run in the OpenWrt shell:
fw_setenv BootImage 1
reboot
Recovery
--------
1. Press Reset button and power on the router
2. Navigate to U-Boot recovery web server (http://192.168.0.1/) and upload
the OEM firmware
MAC addresses
-------------
+---------+-------------------+-------------------+-------------+
| | MAC example 1 | MAC example 2 | Algorithm |
+---------+-------------------+-------------------+-------------+
| label | 68:ff:7b:xx:xx:f4 | 50:d4:f7:xx:xx:da | label |
| LAN | 68:ff:7b:xx:xx:f4 | 50:d4:f7:xx:xx:da | label |
| WAN | 72:ff:7b:xx:xx:f5 | 54:d4:f7:xx:xx:db | label+1 [1] |
| WLAN 2g | 68:ff:7b:xx:xx:f4 | 50:d4:f7:xx:xx:da | label |
| WLAN 5g | 68:ff:7b:xx:xx:f6 | 50:d4:f7:xx:xx:dc | label+2 |
+---------+-------------------+-------------------+-------------+
label MAC address was found in factory at 0x165 (text format
xx:xx:xx:xx:xx:xx).
Notes
-----
[1] WAN MAC address:
a. First octet of WAN MAC is differ than others and OUI is not related
to TP-Link company. This probably should be fixed.
b. Flipping bits in first octet and hex delta are different for the
different MAC examples:
+-----------------+----------------+----------------+
| | Example 1 | Example 2 |
+-----------------+----------------+----------------+
| LAN | 68 = 0110 1000 | 50 = 0101 0000 |
| MAC (1st octet) | ^ ^ ^ | |
+-----------------+----------------+----------------+
| WAN | 72 = 0111 0010 | 54 = 0101 0100 |
| MAC (1st octet) | ^ ^ ^ | ^ |
+-----------------+----------------+----------------+
| HEX delta | 0xa | 0x4 |
+-----------------+----------------+----------------+
| DEC delta | 4 | 4 |
+-----------------+----------------+----------------+
c. DEC delta is a constant (4). This looks like a mistake in OEM
firmware and probably should be fixed.
Based on the above, I decided to keep correct OUI and make WAN MAC =
label + 1.
[2] Bootloaders
The device contains 3 bootloaders:
- First U-Boot: U-Boot 1.1.3 (Mar 18 2019 - 12:50:24). The First U-Boot
located on NAND Flash to load next full-feature Uboot.
- Main U-Boot + its backup: U-Boot 1.1.3 (Mar 18 2019 - 12:50:29). This
bootloader includes recovery webserver. Requires special uImages to
continue the boot process:
0x00 (os0, os1) - firmware uImage
0x40 (os0, os1) - standalone uImage (OpenWrt kernel is here)
- Additionally, both slots of the original TP-Link firmware contains
Image U-Boot: U-Boot 1.1.3 (Oct 16 2019 - 08:14:45). It checks image
magics and CRCs. We don't use this U-Boot with OpenWrt.
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
ELECOM WRC-2533GHBK2-T has the almost same hardware as WRC-2533GHBK-I,
so separate the common parts from dts to dtsi.
Additionaly, add color/function properties to LED nodes and change the
trigger of wlan2g/wlan5g LED to "phy*tpt" trigger.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
While Linus is fine with longer code lines, comments should still be
within the 80 char limit.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
This is an RTL8393-based switch with 48 RJ-45 and 2 SFP ports.
Hardware
--------
SoC: Realtek RTL8393M
RAM: 128MB DDR3 (Nanya NT5CC64M16GP-DI)
FLASH: 8MB NOR (Macronix MX25L6433F)
ETH: 48x 10/100/1000 Mbps RJ-45 Ethernet
SFP: 2x SFP
BTN:
- 1x Reset button
LEDS:
- 50x Green-Amber leds: lan/sfp status
- 1x Green led: power (Always on)
UART:
- 115200-8-N-1 (CN3, pin-out on PCB)
Everything works correctly except for the 2 SFP ports that are not
working unless you enable it every boot in U-Boot with the command:
rtk network on
Installation
------------
You can install Openwrt using one of the following methods.
Warning: flashing OpenWrt will delete your current configuration.
Warning 2: if the -factory.bix file is not available anymore, you must
follow Method 2.
Method 1:
Check the firmware version currently running on your switch. If you are
running FW V1.0.1.10 or greater, you have to download the firmware
V1.0.1.8 from Netgear website and then flash this version. When the
switch restarts, it should be on version V1.0.1.8. Now you can get the
OpenWrt -factory.bix file and then flash it using the OEM web interface.
Method 2 (requires the UART connection):
Boot the -initramfs-kernel.bin image from U-Boot with these commands:
rtk network on;
tftpboot 0x8f000000 openwrt-realtek-rtl839x-netgear_gs750e-initramfs-kernel.bin;
bootm;
And then flash the -sysupgrade.bin file from OpenWrt.
Revert to stock
---------------
Get the stock firmware from the Netgear website and flash it using the
OpenWrt web interface. Remember to not keep the current configuration
and check the "Force upgrade" checkbox
Once reverted to stock the firmware could complain in the UART console
about mtdblock3 and/or mtdblock4 not being mounted correctly but it
seems to work anyway without any problems. Sample error:
mount: Mounting /dev/mtdblock4 on /mntlog failed: Input/output error
If you want to get rid of these error messages you can boot the
-initramfs-kernel.bin image from U-Boot with these commands:
rtk network on;
tftpboot 0x8f000000 openwrt-realtek-rtl839x-netgear_gs750e-initramfs-kernel.bin;
bootm;
And then erase the corresponding partitions using the command:
For mtdblock3:
mtd erase jffs2_cfg
For mtdblock4:
mtd erase jffs2_log
Now you can reboot the switch and the errors should be gone
Note
----
To get the SFP ports fully working, all the right GPIOs must be found.
In the GPL sources I found these:
- GPIO_14: SFP_TX_DIS1;
- GPIO_19: SFP_TX_DIS0;
Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
FACTORY_SIZE is used as a device recipe variable on both the D-Link
DIR-825-B1 and Trendnet TEW-673GRU, but is not listed as a device
variable, neither globally, nor for ath79. Being assigned the same
value, this probably hasn't caused any issues.
Add FACTORY_SIZE to the global list DEFAULT_DEVICE_VARS, to ensure the
variable is reset for every device, and to allow it to be used outside
of the ath79 target.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Changes from version 0.17.1 to version 0.17.2:
- fix incorrect version in 0.17.1
Changes from version 0.17.0 to version 0.17.1:
- Also pass STRIP to the tests
- Fix Out-of-bounds read in the function modifySoname
- Split segment size fix
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
Support for MT7981 and MT7986 has been merged, remove patches.
Tested on a couple of MT7986, MT7622 and MT7623 boards.
MIPS builds are untested.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Currently, ath11k will crash the crash if we try to bringup the monitor
mode interface.
Luckily, it has already been fixed upstream, so backport the patches
fixing it.
Fixes: 93ae4353cd ("mac80211: add ath11k PCI support")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Allign dl_github_archieve.py to 8252511dc0
change. On supported system the sigid bit is applied to files and tar
archieve that on tar creation. This cause unreproducible tar for these
system and these bit should be dropped to produce reproducible tar.
Add the missing option following the command options used in other
scripts.
Fixes: 75ab064d2b ("build: download code from github using archive API")
Suggested-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Tested-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
There is currently a problem with making reproducible version of lldpd.
The tool version is generated based on 3 source:
1. .dist-version file in release tar
2. git hash with presence of .git directory
3. current date
Using the codeload tar from github results in getting the repo without
the .git directory and since they are not release tar, we don't have
.dist-version. This results in having lldpd bin with a version set to
the current build time.
Switch to release tar so that we correctly have a .dist-version file and
the version is not based on the build time.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Robert Marko <robimarko@gmail.com>
This fixes a security problem in ksmbd. It currently has the
ZDI-CAN-18259 ID assigned, but no CVE yet.
Backported from:
8824b7af40cc4f3b5a6a
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Upstream commit [1] included in the Linux kernel version 6.2 was
backported to Linux kernels 6.1.4, 6.0.18. It should be possible that it
is going to be backported even to the 5.15 series, but before it happens,
let's include it here.
It was discovered that on SOC Marvell Armada 3720, which is using e.g.
Turris MOX, and if you are also using it with older ARM Trusted Firmware
v1.5, it is not possible to detect connected USB 3.0 devices, but they
are working just fine when connected with USB 2.0 cable. This patch
fixes it.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/phy/marvell/phy-mvebu-a3700-comphy.c?id=b01d622d76134e9401970ffd3fbbb9a7051f976a
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Michal Hrusecky <michal.hrusecky@turris.com>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
[improve commit description, added tag to the patch]
Test each target if there are additional changes than target/linux.
This is needed to do wide test with changes to kmods, include/kernel and
changes to the workflow files.
While at it also cleanup and rework the code to drop duplication.
Also drop since_last_remote_commit to better track changes.
Fixes: 04ada8bc41 ("CI: kernel: build only changed targets")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
We've few low spec (make -j3) build workers attached to the 22.03
buildbot instance which from time to time exhibit following build
failure during image generation (shortened for brewity):
+ dd bs=512 if=root.ext4 of=openwrt-22.03...sdcard.img.gz.img
dd: failed to open 'root.ext4': No such file or directory
Thats happening likely due to the fact, that on buildbots we've
`TARGET_PER_DEVICE_ROOTFS=y` which produces differently named filesystem
image in the SD card image target dependency chain:
make_ext4fs -L rootfs ... root.ext4+pkg=68b329da
and that hardcoded `root.ext4` image filename becomes available from
other Make targets in the later stages. So lets fix this issue by using
IMAGE_ROOTFS Make variable which should contain proper path to the root
filesystem image.
Fixing remaining subtargets ommited in commit 5c3679e39b ("at91:
sama7: fix racy SD card image generation").
Fixes: 5c3679e39b ("at91: sama7: fix racy SD card image generation")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The board is similar to an APU4 except it has an SFP cage for eth0.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [patch refresh]
We've few low spec (make -j3) build workers attached to the 22.03
buildbot instance which from time to time exhibit following build
failure during image generation:
+ dd bs=512 if=root.ext4 of=openwrt-22.03-snapshot-r20028-43d71ad93e-at91-sama7-microchip_sama7g5-ek-ext4-sdcard.img.gz.img seek=135168 conv=notrunc
dd: failed to open 'root.ext4': No such file or directory
Thats likely due to the fact, that on buildbots we've
`TARGET_PER_DEVICE_ROOTFS=y` which produces differently named filesystem
image in the SD card image target dependency chain:
make_ext4fs -L rootfs ... root.ext4+pkg=68b329da
and that hardcoded root.ext4 becomes available from other target in the
later stages. So lets fix this issue by using IMAGE_ROOTFS Make variable
which should contain proper path to the root filesystem image.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Add concurrency limits for pull request test so that on pull request
refresh old jobs are cancelled.
The group is created based on the github ref + workflow name and the
workflow is cancelled only it it comes from a pull_request event.
Push events are not affected by this limit.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Detect changes in commit and build only changed targets.
If a change is related to the generic target, build test each target.
The matrix json is split. For target check patch only the first
subtarget is selected, for build test each target subtarget is built.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
If for whatever reason external toolchain can't be found or downloaded,
fallback to internal toolchain build.
This can be useful when new target are introduced and external toolchain
are not present in openwrt fileserver.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Refresh upstreamed patch with kernel version tag and replace them with
the upstream version.
For krait-cc patch rework them with the upstream changes.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
BSD based OS have different fixup and doesn't require these header.
Limit these Header to Linux based OS.
Fixes: 36bc306ae6 ("prereq-build: add extra check for elfutils required header")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
STAGING_DIR may be provided from command line. We currently hardcoded
STAGING_DIR_HOST and STAGING_DIR_HOSTPKG to the default location but we
currently have some relocatable patch that derive the path from
STAGING_DIR.
Fix this and correctly derive STAGING_DIR_HOST and STAGING_DIR_HOSTPKG
from STAGING_DIR.
The intention is to fix inconsistency from the relocatable patch and the
use of STAGING_DIR_HOST that is always hardcoded.
This with a wrong configuration may end up in broken state with some
host tools expecing a PATH from STAGING_DIR and others using library
from the default staging_dir/host path.
To save downstream project the original implementation is saved while
fixing the inconsistency between patch and .mk.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
