Now kernel configs of armv6k CPUs don't include CONFIG_CPU_V6.
So armv6k CPUs cannot be detected as arm_v6.
Fix this by adding detection for CONFIG_CPU_V6K.
Signed-off-by: Lu jicong <jiconglu58@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15855
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
`f2fslabel` is already built into `f2fs.fsck`, but is missing its symlink
in the final package.
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/15851
Signed-off-by: Robert Marko <robimarko@gmail.com>
Fixes the following error:
Syntax error: Unable to resolve path for module 'uci'
In line 3, byte 27:
`import * as uci from 'uci';`
Near here ----------------^
Fixes: 4a3ed518b2 ("wifi-scripts: rewrite wifi detect code in ucode")
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
We have to use curly braces on the exported STAGING_DIR_HOST env variable,
instead of evaluating it directly as we are not in Make but a separate
shell script.
Otherwise it would fail with:
staging_dir/host/bin/compile_et: line 6: STAGING_DIR_HOST: command not found
staging_dir/host/bin/mk_cmds: line 5: STAGING_DIR_HOST: command not found
And so when krb5 tries to build it will fail as compile_et and mk_cmds will
return an error.
Fixes: 55bda9863d ("tools/e2fsprogs: fix shell scripts under SDK")
Link: https://github.com/openwrt/openwrt/pull/15854
Signed-off-by: Robert Marko <robimarko@gmail.com>
Needed to fix users of libuuid.a as autoconf applies PIC to only shared
libraries by default.
Found when trying to build python3/host.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15852
Signed-off-by: Robert Marko <robimarko@gmail.com>
These removed compatible strings do not exist in the source code
nor the dt-binding documents. They are useless.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Some devices with MediaTek SoCs don't use the first but only the second
MAC in the chip. Especially with MT7981 which got a built-in 1GE PHY
connected to the second MAC this is quite common.
Make sure to reset and enable PSE also in those cases by skipping gaps
using 'continue' instead of aborting the loop using 'break'.
Fixes: 75081235b8 ("generic: 6.6: (re-)add support multiple PPE to mtk_eth_soc")
Reported-by: Daniel Suchy <danny@danysek.cz>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Switch to netif_napi_add_weight and add back weight value from <= v5.15.
Fixes: 8f6033e287 ("bmips: enet: add compatibility with kernel 6.1")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The bootloader provides the partition table using the boot arguments
and uses the name spi-nor and spi-nand for the different controllers.
The old code was not setting the name any more because mtd->name was
already set before. Move the setting of the name to the spi-mem code
now.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Don't ignore probe requests which contain an invalid DS parameter for the
current operating channel.
As the comment outlines, the drop shall only apply if
dot11RadioMeasurementActivated is set to 1.
However, it was observed Linux clients (Debian 12 / NixOS 23.11)
with an Intel 8265 NIC may generate a probe request frame with
dot11RadioMeasurementActivated set to false and an invalid DSSS
parameter.
These were also dropped even though they should not have been. They
however should not have contained this parameter in the first place.
Don't drop Probe Requests which contain such an invalid field. This may
lead to more probe responses being sent, however it does fix very
frequent connection issues for these clients on 2.4 GHz.
Signed-off-by: David Bauer <mail@david-bauer.net>
These targets are interesting for automated testing. The currently
available targets are from 2017 and either we should enable them again
or delete the remaining files on the download servers.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Link: https://github.com/openwrt/openwrt/pull/15740
Link: https://github.com/openwrt/openwrt/pull/15740
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
7c32295b00 exposed a problem where the SDK
builds these shell scripts with a nonsensical absolute path for the DIR
variable. Use sed to patch in $STAGING_DIR_HOST.
Also remove PKG_RELEASE as that is nonsensical for tools.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15841
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, only the WAN MAC is being populated on Habanero DVK, and that is
happening via the ethernet1 alias so U-Boot does it, previously ethernet0
was implicitly added in the SoC DTSI so it would populate the LAN MAC-s but
it was dropped(rightly so) so now LAN MAC-s and the GMAC one are random.
So, lets simply switch to using NVMEM to assign the proper MAC adresses.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Notify via dev_info when a random MAC address is set.
of_get_ethdev_address can return -EPROBE_DEFER for NVMEM devices,
return this up, so that ipqess can defer as well.
Also move this MAC assignment from _init into _probe, so that this defer
can happen earlier.
Before change, with MAC address allocated from a built-in NVMEM layout
driver (mikrotik,routerboot-nvmem) with extra of_get_ethdev_address
result and random MAC printfs:
[ 1.197571] ipqess-edma c080000.ethernet: ipqess_init of_get_ethdev_address ret:-517, of_node: /soc/ethernet@c080000
[ 1.197690] ipqess-edma c080000.ethernet: generated random MAC address 22:e7:36:e0:e4:a3
[ 1.614444] ipqess-edma c080000.ethernet eth0: entered promiscuous mode
[ 5.055929] ipqess-edma c080000.ethernet eth0: configuring for fixed/internal link mode
after change:
[ 1.173776] ipqess-edma c080000.ethernet: of_get_ethdev_address: -517
[ 1.614607] ipqess-edma c080000.ethernet eth0: entered promiscuous mode
[ 5.246105] ipqess-edma c080000.ethernet eth0: configuring for fixed/internal link mode
[ 5.260754] ipqess-edma c080000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
with extra __func__ printf to show _probe and _init:
[ 1.173685] ipqess-edma c080000.ethernet: ipqess_axi_probe
[ 1.173784] ipqess-edma c080000.ethernet: of_get_ethdev_address: -517
[ 1.280347] ipqess-edma c080000.ethernet: ipqess_axi_probe
[ 1.304844] ipqess-edma c080000.ethernet: ipqess_init
[ 1.614664] ipqess-edma c080000.ethernet eth0: entered promiscuous mode
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
Link: https://github.com/openwrt/openwrt/pull/15831
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that the issue with WED has been sorted out, re-add support for
multiple PPE to the mtk_eth_soc driver.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
"linux,ubi" compatible MTD device can be automatically attached early
since commit fc153aa8d9. Therefore, there is no need to attach MTD
devices named "ubi" or "data" again.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
These things already get built and installed by tools/e2fsprogs. No need
to duplicate.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15822
Signed-off-by: Robert Marko <robimarko@gmail.com>
Used by ethernet interfaces on AP3935i.
Signed-off-by: Bryan Berg <bdb@north-eastham.org>
Link: https://github.com/openwrt/openwrt/pull/13629
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Fix issue with LAN1 interface on ap3935 devices, where the LAN
1interface won't come up after boot unless the bootloader has
initialized the network stack. Use of `fixed-link` in the prior code
kept the driver from clobbering PHY settings, but now that the driver
supports rgmii-id phy-mode, we can just use that.
Signed-off-by: Bryan Berg <bdb@north-eastham.org>
Link: https://github.com/openwrt/openwrt/pull/13629
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Updates ap3935 target to use the mdio controller built-in to gmac0,
rather than having the SoC bit-bang mdio from gpio pins
Signed-off-by: Bryan Berg <bdb@north-eastham.org>
Link: https://github.com/openwrt/openwrt/pull/13629
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This was added to support building coreutils on host systems
that still only have 32-bit time support.
Because other tools now also require the flag for building
with 32-bit time when support for 64-bit time is not present,
this flag is now added to all host builds
on a variable basis using the same test before building,
so it can now be removed from specific tools.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Link: https://github.com/openwrt/openwrt/pull/15799
Signed-off-by: Robert Marko <robimarko@gmail.com>
Several GNU tools such as tar, coreutils, and findutils
now build with support for 64-bit time by default
and otherwise require reconfiguring with a flag
--disable-year2038 in order to build without 64-bit time.
Some standard C libraries, for example,
certain older versions of glibc such as 2.31
have large file support but not long time bits support:
checking for ... option to enable large file support... -D_FILE_OFFSET_BITS=64
checking for ... option for timestamps after 2038... support not detected
This test using C code taken from largefile.m4 in gnulib
uses math and casting to check for overflow
with a macro and array pair that can only be defined
when 64-bit time support is present, and otherwise errors.
It is the exact same code used to test for 64-bit time
during the configure stage of building these tools,
so the results of this test before configure takes place
will always be in concordance with the results of
the test that takes place during the configure script.
Based on the test, the configure flag --disable-year2038
is added to every host tool build depending on the host system.
When the year 2038 problem finally comes around,
the effect of the test can be converted
from the toggling of a configure option into a build prerequisite,
requiring it to pass in order to continue building.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Link: https://github.com/openwrt/openwrt/pull/15799
Signed-off-by: Robert Marko <robimarko@gmail.com>
Specifications:
* SoC: BCM63168
* RAM: NT5CC64M16GP-DI, DDR3 128MiB
* NAND: W29N01HVSINA, 128MiB
* Ethernet: 4x1000M LAN, 1x 1000M WAN
* Serial interface: on board but not populated, 3.3V, 115200, 8N1
Notes:
* Use DSA for VLAN and switches
* Ethernet ports and USB works
* gpio-leds are not working
* WLAN, xDSL, and FXS are not going to work
Signed-off-by: Hang Zhou <929513338@qq.com>
[refactor, reorder, drop unneeded or not working stuff]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Now that util-linux is building libuuid we can simply use that instead
of manually pointing to e2fsprogs libuuid so we can disable building
libuuid in e2fsprogs.
Link: https://github.com/openwrt/openwrt/pull/15806
Signed-off-by: Robert Marko <robimarko@gmail.com>
There is no need to manually only remove 2 binaries during cleanup and
leave rest of the e2fsprogs installed stuff untouched, so instead use
make uninstall to do the cleanup.
Link: https://github.com/openwrt/openwrt/pull/15806
Signed-off-by: Robert Marko <robimarko@gmail.com>
We are now using util-linux to provide libuuid so disable building it
in e2fsprogs and simply use the util-linux provided one.
Disabling libuuid removes the need for custom install recipe.
Link: https://github.com/openwrt/openwrt/pull/15806
Signed-off-by: Robert Marko <robimarko@gmail.com>
util-linux usually provides libuuid, and is preffered by mtd-utils so lets
enable building libuuid so we can disable it later in e2fsprogs.
Only the static version of library is intentionally built.
Link: https://github.com/openwrt/openwrt/pull/15806
Signed-off-by: Robert Marko <robimarko@gmail.com>
Instead of manually installing the binaries and removing them, we can now
simply rely on standard make install/uninstall as we are only building
tools we want to use.
This will be especially important when we start building libraries in
util-linux.
Link: https://github.com/openwrt/openwrt/pull/15806
Signed-off-by: Robert Marko <robimarko@gmail.com>
util-linux supports passing --disable-all-programs configure flag to
disable building anything that isnt then manually enabled.
So, lets switch to using that instead of manually having to disable all
tools we dont need.
However, current drawback is that there is no upstream support for enabling
building hexdump so I included a patch that is pending upstream[0].
[0] https://github.com/util-linux/util-linux/pull/3101
Link: https://github.com/openwrt/openwrt/pull/15806
Signed-off-by: Robert Marko <robimarko@gmail.com>
Release notes:
https://lists.infradead.org/pipermail/linux-mtd/2024-March/104058.html
mtd-utils are currently depending on zlib, however it is not expressed
as a dependency and it is somehow being only pulled-in by lincurses-devel
so mtd-utils were able to compile.
Since 2.2.0 zlib is optional so lets disable support for it like for other
compressors since we dont package the mkfs.ubifs or mkfs.jffs2 that
are only users of compressors anyway.
Link: https://github.com/openwrt/openwrt/pull/15802
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that we are not patching mtd-utils with JFFS2 LZMA support there
is no need for autoreconf to be run.
Link: https://github.com/openwrt/openwrt/pull/15802
Signed-off-by: Robert Marko <robimarko@gmail.com>
Turns out the device got two buttons, while the currently listed on is
actually WPS, and the other (will hidden) button is intended as RESET.
Update DT accordingly.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Passing --disable-tests does not do anything since upstream commit [0]
("Fix test binary installation") as that commit removed it since there is
already and existing --without-tests compile option to not compile
the tests at all as --disable-tests was just disabling their installation.
So, lets just pass --without-tests instead to disable test compilation.
[0] https://git.infraroot.at/mtd-utils.git/commit/?id=7170a28d46d5db1e7a9da24a5555a194a233ef0b
Fixes: 67efb6a661 ("tools: mtd-utils: Update to version 2.1.4")
Link: https://github.com/openwrt/openwrt/pull/15791
Signed-off-by: Robert Marko <robimarko@gmail.com>
Release notes:
https://lists.infradead.org/pipermail/linux-mtd/2024-March/104058.html
Manually refresh the portability and JFFS2 LZMA patches.
Since mtd-utils have converted most of the JFFS2 compressors to be compile
time configurable and manual refreshing of JFFS2 LZMA was needed I also
converted it to a compile time option and enabled the new --with-lzma
option.
Link: https://github.com/openwrt/openwrt/pull/15791
Signed-off-by: Robert Marko <robimarko@gmail.com>
Remove unneeded default-state from led_power_green (led@8) to be in line with
other bmips devices.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Remove unneeded default-state from led_power_green (led@4) to be in line with
other bmips devices.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Replace Aquantia pending LEDs patch with upstream version.
Sadly net maintainers didn't like integrated solution hence we still
need to handle LED restore on reset with custom solution.
Link: https://github.com/openwrt/openwrt/pull/15797
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
We have been carrying the 100-fix_includes.patch and 130-lzma_jffs2.patch
for a long time but the reason is lost to history.
We dont need to carry the JFFS2 LZMA support patch as mkfs.jffs2 is not
even being packaged so its not even being used.
As for the 100-fix_includes.patch that also seems like a relic of history
as mtd-utils compiles fine without it.
So, lets drop both patches.
Link: https://github.com/openwrt/openwrt/pull/15790
Signed-off-by: Robert Marko <robimarko@gmail.com>
