Re: mt7621 GPIO mapping mystery
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as GPIO by default. Requesting a gpio by either from devicetree or `echo 203 > /sys/class/gpio/export` won't change anything. You have to claim the pin group as gpio on the devicetree. Quoting my response from [0]: state_default is there to explicitly set the function of a pin group to gpio, this is done because the bootloader may have set the function of a pin group to something else before booting OpenWrt which would render the pins of that group uncontrollable for general purpose aka GPIO. Actually I think @arinc9 did some work around that. Not yet, I plan to modify the gpio_request_enable pinmux operation to set the pin group as gpio when there's a gpio request for a pin in that pin group. gpio_request_enable pinmux operation can only set the function of an individual pin currently. Since ralink pinctrl driver can only set the function of a group of pins, the operation currently cannot be used. If we make it work, any GPIO defined on devicetree or exported from userspace will automatically have the function of the pin group it's in set to gpio, completely getting rid of the need for explicitly defining functions of certain pin groups on the devicetree. Of course when I said "I plan to modify this code" I actually meant I was going to talk this through with Sergio but I never had the opportunity to do so. I guess this thread is a good place to start talking about this. I had this case on a user: They got an LED wired to wdt pin. GPIO is already exported on the DT. However their LED just won't work. It turns out the bootloader sets the wdt pin's function to something other than gpio. And when OpenWrt boots, the pinctrl driver makes no changes to the pin's function. So we had to specifically claim that pin as gpio to make the LED work. Now there is already a solution for this which is the gpio_request_enable pinmux operation but it's not supposed to be used on pinctrl drivers that cannot control pins individually. Sergio, you think we can somehow make this pinmux operation mux a pin group as gpio instead of a single pin? Or introduce a new pinmux operation that can do this? [0] https://github.com/openwrt/openwrt/pull/4470#issuecomment-1243345944 Arınç On 20.01.2023 22:24, Peter Naulls wrote: I posted previously on GPIOs, which caused some debate; this may or may not be relevant, but I'd be remiss to not mention it: http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt 5.10.161 etc kernels. In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17 and 22-24 are LEDs, so their operation should be immediately obvious. The are all active high and are all wired as you'd expect. This all works as expected on a previous 4.14 kernel. To say that there have been significant changes in drivers, GPIO handling and device tree since that kernel would be an understatement. I have tried exporting the GPIOS as LEDs, named GPIOs, direct manipulation in /sys/class/gpio and libgpiod, but something is amiss. The actual value of the GPIO as seen in software can manipulated in all cases, but the physical value does not change. Suspiciously, MDIO/MDC are at GPIOs 20 and 21, so I don't know if these are upsetting the physical mapping. I've also turned off as much as possible in the device tree, and built the kernel without switch and ethernet drivers, etc. I'm tearing my hair out here, so any clues at all would be appreciated. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Sat, Jan 21, 2023 at 02:23:08AM +0100, Christian Marangi wrote: > On Fri, Jan 20, 2023 at 05:17:43PM -0800, Brian Norris wrote: > > On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi > > wrote: > > > added the changed to my staging repo and testing them here > > > https://github.com/openwrt/openwrt/pull/11843. > > > > > > Merged the fstools requirement. If CI tests doesn't have problems, i > > > will merge this in master. > > > > I see you've merged them to master. Thanks for looking and for > > merging! I'll keep an eye out myself, but feel free to let me know if > > anything goes wrong. > > > > One preemptive heads up: I know my ASoC/sound patch already got merged > > to Linux v5.15.89, so that patch should drop out whenever openwrt > > pulls it in. Presumably whoever does that upgrade will notice the > > conflict/redundancy eventually. > > > > Yes CI test will catch that and will just fail. Good enough. > Now I think I have to > ask someone to reboot buildbot again for the new subtarget... Or it will be > picked automatically? I'm certainly not the expert, but last I dealt with this I hear it needed a restart: https://github.com/openwrt/openwrt/pull/9276#issuecomment-1085448201 Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Fri, Jan 20, 2023 at 05:17:43PM -0800, Brian Norris wrote: > On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi > wrote: > > added the changed to my staging repo and testing them here > > https://github.com/openwrt/openwrt/pull/11843. > > > > Merged the fstools requirement. If CI tests doesn't have problems, i > > will merge this in master. > > I see you've merged them to master. Thanks for looking and for > merging! I'll keep an eye out myself, but feel free to let me know if > anything goes wrong. > > One preemptive heads up: I know my ASoC/sound patch already got merged > to Linux v5.15.89, so that patch should drop out whenever openwrt > pulls it in. Presumably whoever does that upgrade will notice the > conflict/redundancy eventually. > Yes CI test will catch that and will just fail. Now I think I have to ask someone to reboot buildbot again for the new subtarget... Or it will be picked automatically? -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
CC: Sergio On Fri, Jan 20, 2023 at 11:29 AM Peter Naulls wrote: > > > > I posted previously on GPIOs, which caused some debate; this may or may not > be relevant, but I'd be remiss to not mention it: > > http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html > > I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt > 5.10.161 etc kernels. > > In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17 and > 22-24 are LEDs, so their operation should be immediately obvious. The are all > active high and are all wired as you'd expect. > > This all works as expected on a previous 4.14 kernel. To say that there > have been significant changes in drivers, GPIO handling and device tree since > that kernel would be an understatement. > > I have tried exporting the GPIOS as LEDs, named GPIOs, direct manipulation in > /sys/class/gpio and libgpiod, but something is amiss. The actual value of the > GPIO as seen in software can manipulated in all cases, but the physical value > does not change. > > Suspiciously, MDIO/MDC are at GPIOs 20 and 21, so I don't know if these are > upsetting the physical mapping. I've also turned off as much as possible in > the device tree, and built the kernel without switch and ethernet drivers, > etc. > > I'm tearing my hair out here, so any clues at all would be appreciated. > > Thanks! > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi wrote: > added the changed to my staging repo and testing them here > https://github.com/openwrt/openwrt/pull/11843. > > Merged the fstools requirement. If CI tests doesn't have problems, i > will merge this in master. I see you've merged them to master. Thanks for looking and for merging! I'll keep an eye out myself, but feel free to let me know if anything goes wrong. One preemptive heads up: I know my ASoC/sound patch already got merged to Linux v5.15.89, so that patch should drop out whenever openwrt pulls it in. Presumably whoever does that upgrade will notice the conflict/redundancy eventually. Thanks, Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
mt7621 GPIO mapping mystery
I posted previously on GPIOs, which caused some debate; this may or may not be relevant, but I'd be remiss to not mention it: http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt 5.10.161 etc kernels. In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17 and 22-24 are LEDs, so their operation should be immediately obvious. The are all active high and are all wired as you'd expect. This all works as expected on a previous 4.14 kernel. To say that there have been significant changes in drivers, GPIO handling and device tree since that kernel would be an understatement. I have tried exporting the GPIOS as LEDs, named GPIOs, direct manipulation in /sys/class/gpio and libgpiod, but something is amiss. The actual value of the GPIO as seen in software can manipulated in all cases, but the physical value does not change. Suspiciously, MDIO/MDC are at GPIOs 20 and 21, so I don't know if these are upsetting the physical mapping. I've also turned off as much as possible in the device tree, and built the kernel without switch and ethernet drivers, etc. I'm tearing my hair out here, so any clues at all would be appreciated. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] Remove ccache wrappers
These wrappers are not needed as CC doesn't need to be a single word.
a53b084e497a9f1629a2caada833ebe14a6838b7 which introduced the wrappers
doesn't explain why they were really needed and why only for the target
and not for the host.
Moreover, name of the wrappers breaks a ccache assumption: since
v4.0-3-g6a92b4cd3a67 it has special handling for "chained" invocation
such as "ccache ccache gcc" where it skips all the "ccache*" names in
the middle and proceeds to run as if it was started as "ccache
gcc"[1][2].
This becomes important when a build system sees ccache in the PATH and
automatically enables it by prepending to CC. An example of such a
system would be autosetup as used by jimtcl. With the wrappers it breaks
as the command line ends up being just "ccache -Os..." because
"ccache_cc" gets skipped as it starts with "ccache".
[1] https://github.com/ccache/ccache/blob/master/src/ccache.cpp#L2105
[2] https://github.com/ccache/ccache/blob/master/src/Util.cpp#L802
Reported-by: Karl Palsson
Signed-off-by: Paul Fertser
---
I tried CONFIG_ALL=y build and fixed bad packaging where I noticed:
https://github.com/openwrt/packages/pull/20353
Also sent a patch for Alpine (in private) and a patch/bug report to
libicu upstream: https://github.com/unicode-org/icu/pull/2290 .
My notion is that properly fixing affected software is better in the
long run. However just renaming the wrappers is an option too if it's
much less painful in the end. One potential downside would be that the
build systems wouldn't be able to detect e.g. GCC vs clang if used
with a wrapper and wouldn't apply custom build flags.
rules.mk | 4 ++--
tools/ccache/Makefile | 10 --
tools/ccache/files/ccache_cc | 2 --
tools/ccache/files/ccache_cxx | 2 --
4 files changed, 2 insertions(+), 16 deletions(-)
delete mode 100755 tools/ccache/files/ccache_cc
delete mode 100755 tools/ccache/files/ccache_cxx
diff --git a/rules.mk b/rules.mk
index 3d151338af11..a2f5bcca4b0d 100644
--- a/rules.mk
+++ b/rules.mk
@@ -283,8 +283,8 @@ export HOSTCC_NOCACHE
export HOSTCXX_NOCACHE
ifneq ($(CONFIG_CCACHE),)
- TARGET_CC:= ccache_cc
- TARGET_CXX:= ccache_cxx
+ TARGET_CC:= ccache $(TARGET_CC)
+ TARGET_CXX:= ccache $(TARGET_CXX)
HOSTCC:= ccache $(HOSTCC)
HOSTCXX:= ccache $(HOSTCXX)
export CCACHE_BASEDIR:=$(TOPDIR)
diff --git a/tools/ccache/Makefile b/tools/ccache/Makefile
index 25ab4a46eabe..6824dbddfd40 100644
--- a/tools/ccache/Makefile
+++ b/tools/ccache/Makefile
@@ -28,14 +28,4 @@ ifneq (docs-$(CONFIG_BUILD_DOCUMENTATION),docs-y)
CMAKE_HOST_OPTIONS += -DENABLE_DOCUMENTATION=OFF
endif
-define Host/Install/ccache
- $(INSTALL_DIR) $(STAGING_DIR_HOST)/bin/
- $(CP) ./files/* $(STAGING_DIR_HOST)/bin/
-endef
-
-define Host/Install
- $(call Host/Install/Default)
- $(call Host/Install/ccache)
-endef
-
$(eval $(call HostBuild))
diff --git a/tools/ccache/files/ccache_cc b/tools/ccache/files/ccache_cc
deleted file mode 100755
index 01c4ad42a21d..
--- a/tools/ccache/files/ccache_cc
+++ /dev/null
@@ -1,2 +0,0 @@
-#!/bin/sh
-exec ccache "${TARGET_CC_NOCACHE}" "$@"
diff --git a/tools/ccache/files/ccache_cxx b/tools/ccache/files/ccache_cxx
deleted file mode 100755
index cc60eb3a13c7..
--- a/tools/ccache/files/ccache_cxx
+++ /dev/null
@@ -1,2 +0,0 @@
-#!/bin/sh
-exec ccache "${TARGET_CXX_NOCACHE}" "$@"
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Thu, Jan 12, 2023 at 09:32:22PM -0800, Brian Norris wrote: > TP-Link and ASUS OnHub devices are very similar, sharing many of the > same characteristics and much of their Device Tree. They both run a > version of ChromeOS for their factory firmware, and so installation > instructions look very similar to Google Wifi [1]. > > Things I've tested, and are working: > > * Ethernet > * WiFi (2.4 and 5 GHz) > * LEDs > * USB > * eMMC > * Serial console (if you wire it up yourself) > * 2x CPU > * Speaker > > == Installation instructions summary == > > 1. Flash *-factory.bin to a USB drive (e.g., with `dd`) > 2. Insert USB drive, to boot OpenWrt from USB > 3. Copy the same *-factory.bin over to device, and flash it to eMMC to >make OpenWrt permanent > > == Developer mode, booting from USB (Step 2) == > > To enter Developer Mode and boot OpenWrt from a USB stick: > > 1. Unplug power > 2. Gain access to the "developer switch" through the bottom of the >device > 3. Hold down the "reset switch" (near the USB port / power plug) > 4. Plug power back in > 5. The LED on the device should turn white, then blink orange, then >red. Release the reset switch. > 6. Insert USB drive with OpenWrt factory.bin > 7. Press the hidden developer switch under the device to boot to USB; >you should see some activity lights (if you have any) on your USB >drive > 8. Depending on your configuration, the router's LED(s) should come on. >You're now running OpenWrt off a USB stick. > > These instructions are derived from: > > https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub > https://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub > > ~~Finding the developer switch:~~ for TP-Link, the developer switch is > on the bottom of the device, underneath some of the rubber padding and a > screw. For ASUS, remove the entire base, via 4 screws under the rubber > feet. See the Exploitee instructions for more info and photos. > > == Making OpenWrt permanent (on eMMC) (Step 3) == > > Once you're running OpenWrt via USB: > > 1. Connect Ethernet to the LAN port; router's LAN address should be at >192.168.1.1 > 2. Connect another system to the router's LAN, and copy the factory.bin >image over, via SCP and SSH: > > scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin > root@192.168.1.1: > ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 > of=/dev/mmcblk0 count=33 && \ > dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin > of=/dev/mmcblk0" > 3. Reboot and remove the USB drive. > > == Developer mode beep == > > Note that every time you boot the OnHub in developer mode, the device > will play a loud "beep" after a few seconds. This is described in the > Chromium docs [2], and is intended to make it clear that the device is > not running Google software. It is nontrivial to completely disable this > beep, although it's possible to "acknowledge" developer mode (and skip > the beep) by using a USB keyboard to press CTRL+D every time you boot. > > [1] https://openwrt.org/toh/google/wifi > [2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md > > Signed-off-by: Brian Norris Hi, added the changed to my staging repo and testing them here https://github.com/openwrt/openwrt/pull/11843. Merged the fstools requirement. If CI tests doesn't have problems, i will merge this in master. > --- > * There might be better ways to handle the multi-color LED support, >but for now, each color is a separate LED > * A variety of people have been interested in this work, and a few have >tested versions of it already: > https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899 > * This is dependent on an fstools change, to ensure it can find our >'rootfs_data' properly: > [PATCH fstools v2] partname: Ignore root=PARTUUID... > > https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/ > > Changes in v4: > * move LED configuration to device tree > > Changes in v3: > * use 'ucode' for base64, to reduce dependency complexity and avoid >bringing in coreutils > * simplify installation instructions > * add back in second CPU / drop maxcpus=1 (I had apparently already >fixed this, but kept the maxcpus=1) > > Changes in v2: > * Drop custom ath10k base64 property > * Provide base64 caldata parsing via >/etc/hotplug.d/firmware/11-ath10k-caldata instead > * add coreutils-base64 dependency > * add 3rd (rootfs_data) partition, to better handle sysupgrade and >utilize the whole disk > > target/linux/ipq806x/Makefile | 4 +- > .../ipq806x/base-files/etc/board.d/02_network | 6 + > .../etc/hotplug.d/firmware/11-ath10k-caldata | 35 ++ > .../base-files/lib/upgrade/platform.sh| 19 + > .../base-files/usr/bin/base64decode.uc
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 2023-01-20 13:24, Florian Eckert wrote: On 2023-01-20 12:49, Felix Fietkau wrote: On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. Thanks. I don't have a strong opinion one way or the other, but I think the code might be more readable without the explicit $(STAGING_DIR_HOST)/bin prefix. Your right It works regardless of whether the prefix is there or not. But I would just like to note that it is easier to see whether the tools are now used from staging or the build host. The tool mkisofs https://github.com/openwrt/openwrt/blob/master/target/linux/x86/image/Makefile#L100, for example, is used from the build host! There is indeed a guard here https://github.com/openwrt/openwrt/blob/master/target/linux/x86/Makefile. But I am not sure if this is the case everywhere and if it is clear to everyone which tool is now being used during development. I just wanted to say that I am more in favor of explicitly select which tool is now being used. I think the actual tool used should be in a variable, like $(STAGING_HOST_SED). This is very readable and it also makes the list of tools used explicitly known. The PATH must still be set for tools to find other staging dir tools. Actually, the host path should be unset to avoid inadvertently using the host tools instead of the one of the staging dir. I personally would prefer using a chroot-ed staging host to avoid any host interference. Regards, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
On 2023-01-20 12:49, Felix Fietkau wrote: On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. Thanks. I don't have a strong opinion one way or the other, but I think the code might be more readable without the explicit $(STAGING_DIR_HOST)/bin prefix. Your right It works regardless of whether the prefix is there or not. But I would just like to note that it is easier to see whether the tools are now used from staging or the build host. The tool mkisofs https://github.com/openwrt/openwrt/blob/master/target/linux/x86/image/Makefile#L100, for example, is used from the build host! There is indeed a guard here https://github.com/openwrt/openwrt/blob/master/target/linux/x86/Makefile. But I am not sure if this is the case everywhere and if it is clear to everyone which tool is now being used during development. I just wanted to say that I am more in favor of explicitly select which tool is now being used. - Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. Thanks. I don't have a strong opinion one way or the other, but I think the code might be more readable without the explicit $(STAGING_DIR_HOST)/bin prefix. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. - Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
On 20.01.23 09:36, Florian Eckert wrote: During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Signed-off-by: Florian Eckert --- target/linux/x86/image/Makefile | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile index 322131c2a4..66d914681d 100644 --- a/target/linux/x86/image/Makefile +++ b/target/linux/x86/image/Makefile @@ -59,7 +59,7 @@ endef define Build/grub-config rm -fR $@.boot $(INSTALL_DIR) $@.boot/boot/grub - sed \ + $(STAGING_DIR_HOST)/bin/sed \ -e 's#@SERIAL_CONFIG@#$(strip $(GRUB_SERIAL_CONFIG))#g' \ -e 's#@TERMINAL_CONFIG@#$(strip $(GRUB_TERMINAL_CONFIG))#g' \ -e 's#@ROOTPART@#root=$(ROOTPART) rootwait#g' \ @@ -91,9 +91,12 @@ define Build/iso > $@.boot/boot/grub/eltorito.img -$(CP) $(STAGING_DIR_ROOT)/boot/. $@.boot/boot/ $(if $(filter $(1),efi), - mkfs.fat -C $@.boot/boot/grub/isoboot.img -S 512 1440 - mmd -i $@.boot/boot/grub/isoboot.img ::/efi ::/efi/boot - mcopy -i $@.boot/boot/grub/isoboot.img \ + $(STAGING_DIR_HOST)/bin/mkfs.fat \ + -C $@.boot/boot/grub/isoboot.img -S 512 1440 + $(STAGING_DIR_HOST)/bin/mmd \ + -i $@.boot/boot/grub/isoboot.img ::/efi ::/efi/boot + $(STAGING_DIR_HOST)/bin/mcopy \ + -i $@.boot/boot/grub/isoboot.img \ $(STAGING_DIR_IMAGE)/grub2/iso-boot$(if $(CONFIG_x86_64),x64,ia32).efi \ ::/efi/boot/boot$(if $(CONFIG_x86_64),x64,ia32).efi ) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
