Re: Objective of OpenWRT/x86?
On Thu, May 4, 2023 at 7:35 AM Elliott Mitchell wrote: > On Thu, May 04, 2023 at 03:50:05AM +0100, Daniel Golle wrote: > > On Wed, May 03, 2023 at 06:36:10PM -0700, Elliott Mitchell wrote: > > > On Tue, May 02, 2023 at 02:45:43AM +0200, Alberto Bursi wrote: > > > > On 26/04/23 22:17, Elliott Mitchell wrote: > Something is very wrong here. > > Question is whether it is deliberate versus accidental. > > One possibility is you last looked at an OpenWRT x86 5.10 kernel and > figured the number would be roughly in line with 5.15. In this case > there was a rather drastic increase in size between 5.10 and 5.15 for > x86. > > Another possibility which comes to mind is that is pretty close to the > x86 5.15 compressed image size. I would expect you to be aware modern > data compression algorithms are fairly effective and can often provide > substantial reductions. I suppose you could be unaware of this, but > given how well known this is I would be left suspecting deliberate > distortion. > > The last generic OpenWRT x86 5.15 image I built less than a week ago > produced a roughly 28MB vmlinux.bin file. Some of that disappears since > initialization portions will be freed after boot, but this is fairly > representative of runtime use (additional will be used for what is found > during boot). > > My most recent OpenWRT based image which was moderately adapted to a > specific target (running in a Xen VM) was 18MB. *That* is substantial > enough to go after. Here are memory figures for a fully initialized OpenWrt x86/64 QEMU systems. Very easy for anyone capable of proposing kernel configuration patches to try themselves. $ qemu-system-x86_64 -nodefaults -smp 2 -m 128 -vga std -nic user,model=virtio -nic user,model=virtio -drive file=openwrt.img,format=raw,if=virtio # opkg update && opkg install luci && reboot https://downloads.openwrt.org/releases/22.03.5/targets/x86/64/openwrt-22.03.5-x86-64-generic-ext4-combined.img.gz Kernel: 5.10.176 /boot/vmlinuz size: 5.0M Memory used after boot settles: ~44M https://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-generic-ext4-combined.img.gz Kernel: 5.15.110 /boot/vmlinuz size: 5.6M Memory used after boot settles: ~46M (Caveat: snapshot build) > Is OpenWRT/x86 a networking device Linux distribution? > Yet again, I'm asking the question: What is THE goal of OpenWRT/86? > Is OpenWRT/x86 aiming to be a desktop Linux distribution? No, but everything else is as modular as possible through packages etc so people can do whatever they want with it. Even routing packets. Good container support will mean the OpenWrt distribution itself won't ever need to grow into something like Debian and can stay focused on embedded/networking use cases. From https://openwrt.org/ : > The OpenWrt Project is a Linux operating system targeting embedded devices. > Instead of trying to create a single, static firmware, OpenWrt provides a > fully writable filesystem with package management. This frees you from the > application selection and configuration provided by the vendor and allows you > to customize the device through the use of packages to suit any application. > For developers, OpenWrt is the framework to build an application without > having to build a complete firmware around it; for users this means the > ability for full customization, to use the device in ways never envisioned > Is OpenWRT/x86 a developer test simulator for "real" OpenWRT targets? It is a real target that people and companies use daily for their packet routing needs. Also, the best test target would be... a real target. > Is OpenWRT/x86 a networking device Linux distribution? More or less I'd say. OpenWRT/x86 is just a build of OpenWrt that runs on x86. so it's mainly focused on providing a good out-of-the-box network router. Plug in NICs and they just show up. It just so happens that the x86 platform/ecosystem has more diverse boot-related hardware than specific isolated targets, which will make the kernels a little bigger than other focused targets. You can choose to use a serial console, or choose to use a VGA console. It simply works out-of-the-box in a few minutes on most x86 hardware or x86 VMs. Wonderful. I'd say this is the single most important feature of the x86 target, that it just works out of the box. Its now 2023. No-one has time to be recompiling kernels when they just need a reliable router now while juggling work and family. If you handed over a work-critical networking appliance with hand-rolled kernels to your work colleagues to maintain, you might as well have handed them a barnfire. So its good the x86 targets just work without any messing due to being too lean. --- The original issue raised in these threads is centered around the perception that the default build/install of the x86 targets have excessive memory usage in different scenarious, along with various patches and suggestions for cutting this down. However simple testing like above shows this isn't
Re: Objective of OpenWRT/x86?
On Mon, May 1, 2023 at 5:43 AM Philip Prindeville wrote: >> On Apr 28, 2023, at 11:18 PM, Elliott Mitchell wrote: >>> On Fri, Apr 28, 2023 at 12:04:15PM -0600, Philip Prindeville wrote: >>> Um... you can't "virtualize" WiFi in any VM I've ever seen. >> >> You can though pass PCIe devices to a VM. The hardware will physically >> attach to the control host, but a VM will be able to do anything it wants >> with it. > > So the guest has the potential to crash or hang the host? I ran the OpenWrt x86/64 image under KVM/libvirtd for years with an Intel Wifi card connected through exclusive PCI passthrough, and it worked fine. There is enough conjecture already. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
As you point out elsewhere, this "optional builtin modules" problem is typically solved with bootstrapping initrd images. But adding something like initramfs-tools or dracut into OpenWrt would be over complicating things, since the current x86/64 images seem to suit everyone. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
On Sat, Apr 29, 2023 at 3:29 AM Elliott Mitchell wrote: > I'm looking at the list of built-in drivers and seeing many which > will perhaps only be used by 25% of installations. That figure seems hypothetical, but you would propose to break 25% of users installations for insignificant memory reductions? >>> Problem is instead of the recommended 128MB memory, 16MB of storage >>> (https://openwrt.org/supported_devices/432_warning) the virtualization >>> examples (https://openwrt.org/docs/guide-user/virtualization/start) are >>> suggesting massively more memory. 256MB (small Xen example), 512MB >>> (VMware OpenWRT/15.05) or 1GB (Qemu examples). >> It makes more sense to make a new lightweight VM profile rather than >> chopping stuff out of the generic ones. >> But is one needed, and how much memory would be saved? Have you >> actually tried running the "x86/64" image with 128MB ram under QEMU? >> Default 22.03.4 install shows 45MB used. With "wpad-openssl" and >> "kmod-mac80211-hwsim", its up to 53MB. These requirements rise >> depending on load. I'm guessing those memory figures in the wiki docs >> are just arbitrary, showing people they can run cool stuff. > That could be. Might simply be the wiki needs to have numbers adjusted > downwards to reflect how much memory a reasonable installation needs > instead of an advanced doing all the things installation. This misunderstanding seems to be what drove this discussion and patch series, along with wanting to cleanup "legacy" functionality others still use. Granted, there doesn't seem to be a x86/64 "minimum reqiurements" requirements in the Wiki which would help clear this up. Probably because they are so low that people don't really care. The forums also have a few questions asking about minimum requirements, but the answers are vague. > As far as creating a slimmed-down VM kernel configuration. Removing AGP > support doesn't gain much itself, but then disabling DRM support saves > 2203648 bytes. Turning USB support into modules is another 2MB. I've > gotten a potentially viable Xen kernel down to 23MB, but I hope to push > at least somewhat further. I'm not a developer, but these gains don't seem significant enough to justify a new virt profile when the current generic x86/64 images will simply work out of the box. The only real benefits of a slimmed down virt specific kernel would be a reduced attack surface (even though the code for undetected devices should be inactive). But to really commit to that minimal security footprint would require seperate virt profiles for every VM platform etc. A lot of work to undertake for a contemplative discussion... - Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
One nice feature for users of the "x86/64" and similar builds are that they work out of the box on most generic hardware or virtualization platforms. I use it on real hardware and KVM with device passthrough, and it was very easy to set up. I'm guessing this is far more common than speculative high density VM deployments. It makes more sense to make a new lightweight VM profile rather than chopping stuff out of the generic ones. But is one needed, and how much memory would be saved? Have you actually tried running the "x86/64" image with 128MB ram under QEMU? Default 22.03.4 install shows 45MB used. With "wpad-openssl" and "kmod-mac80211-hwsim", its up to 53MB. These requirements rise depending on load. I'm guessing those memory figures in the wiki docs are just arbitrary, showing people they can run cool stuff. If memory usage optimization is the goal, I suggest these discussions and patches be tested and informed by real measurements in that area, to discuss whether the tradeoffs with compatability are worth it. - Joe On Wed, Apr 26, 2023 at 9:19 PM Elliott Mitchell wrote: > > Well, was a specific objective ever chosen for the x86 version of > OpenWRT? > > I can state my goal/hope for OpenWRT/x86. The *WRT Linux distributions > were so named for originally targeting the LinkSys WRT54G. This was a > small AP, so one might expect builds to be for small APs. By today's > standards 128MB RAM and 16MB of storage is relatively small. > > Since this network is in the moving towards the server phase, the AP drew > my attention. Turns out all of the hardware of an AP is available for > servers, though in distinct form-factors. If the server has a full > IOMMU, the hardware can be directed to a VM and you have a proper AP in a > VM. > > Problem is instead of the recommended 128MB memory, 16MB of storage > (https://openwrt.org/supported_devices/432_warning) the virtualization > examples (https://openwrt.org/docs/guide-user/virtualization/start) are > suggesting massively more memory. 256MB (small Xen example), 512MB > (VMware OpenWRT/15.05) or 1GB (Qemu examples). > > > I don't yet have a full handle on the issues. My first thought was the > large sizes come from early stage development and not wanting to bother > with memory limitations. Another possibility is this comes from simply a > thought pattern of "x86 memory is cheap, just throw memory at it". > > Yet if one is wanting to use this for serious purposes, memory IS a > concern. GCC is pretty capable for x86, a quick check suggests GCC tends > to produce binaries for x86 which are four-fifths the size of those for > ARM. Yet everything for OpenWRT/x86 is suggesting at least *double* the > memory?! > > > One issue I've found is the kernel configurations seem ill-suited to x86. > Almost any storage driver used by 10 or more people is built into the > kernel. As a result the *single* kernel is huge. > > The conventional approach for x86 is to use an initial ramdisk and build > everything as modules. Issue here is OpenWRT doesn't currently have the > scripting/tools for runtime probing of a storage subsystem. I think this > is a fine approach if the committers are up for all the change this will > entail. > > Alternatively x86 could be broken into more builds. This would emulate > how OpenWRT works for all other devices. "generic" would likely be 2-3 > distinct builds. "64" would be 4-6 distinct builds. Issue here is how > many distinct builds should be created? > > If one was to go this direction, I suppose there might be "giant" or > "desktop" build. Each hypervisor could use a target, include "hardware" > guaranteed to be present. Then build all network drivers as modules (so > any device can be passed-in). > > > > Examples of things which don't seem to fit well are CONFIG_AGP and > CONFIG_DRM. I would expect those for a desktop Linux distribution due > to GUI. For OpenWRT which tends towards networking/embedded those seem > out of place. CONFIG_FB is similar, though some devices do have actual > limited frame-buffers. > > Another item is the goal of trying to self-host. Being able to self-host > is a worthy goal, but that has very distinct needs from an embedded > networking device. > > > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+sig...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > ___ > 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: next OpenWrt 22.03 and 21.02 minor release
On Tue, Mar 28, 2023 at 11:44 AM Paul Spooren wrote: > > > > How should simple github PRs that are intended be applied to both > > /master and /openwrt-22.03 be handled? > > Feel free to open both at the same time to have the CI running, however be > sure to mark the backport as “draft” and once committed to the main branch, > cherry-pick it with -x so we got a commit reference. > > > (Where the long way would be: first open a PR to /master then come > > back and open another PR to cherry-pick back to /openwrt-22.03) > > We had issues with “trivial” locking backports, skipping a day or two of > waiting isn’t worth the risk in my opinion. Thanks, I will do so now. My own recent PR is such an example, it mistakenly includes a kernel patch for Linux 5.15 which doesn't exist on /openwrt-22.03 , which the CI testing would probably catch :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: next OpenWrt 22.03 and 21.02 minor release
> If we should backport more changes please create a pull request on > github, send a patch with the 22.03 or 21.02 prefix to the mailing list > or send a mail with a link to the master commit we should backport as an > answer to this mail and I will have a look at the commit. How should simple github PRs that are intended be applied to both /master and /openwrt-22.03 be handled? (Where the long way would be: first open a PR to /master then come back and open another PR to cherry-pick back to /openwrt-22.03) Thanks On Mon, Mar 27, 2023 at 11:57 PM Hauke Mehrtens wrote: > > Hi, > > I would like to create a new OpenWrt 22.03 and 21.02 minor release in > the next week. > > OpenWrt 21.02.6 would be the final release of the OpenWrt 21.02 series. > > On github the following pull requests are tagged for the releases: > https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F22.03 > https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F21.02 > > If we should backport more changes please create a pull request on > github, send a patch with the 22.03 or 21.02 prefix to the mailing list > or send a mail with a link to the master commit we should backport as an > answer to this mail and I will have a look at the commit. > > Hauke > > ___ > 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
GitHub mirror for firmware-utils Inbox
Hi all, Can a GitHub mirror be created for https://git.openwrt.org/project/firmware-utils.git ? It seems every major part of the project already has one: https://openwrt.org/submitting-patches#deciding_where_to_send_the_patch Some time ago firmware-utils was split from the main repo. Some devices require coordinated changes and reviews between firmware-utils and DTS/profiles (e.g. tplink-safeloader), and this will make things a lot easier for contributors. Thanks. [1] https://github.com/openwrt/openwrt/issues/11185 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Seperating firmware-utils into seperate repo
> Most in-house OpenWrt packages are actually stored in their > own git repo, see https://git.openwrt.org/ down in the > /project/something_something.git > > -Alberto Thanks for the good suggestions Alberto. I still think it will be a messy process for most new device contributors (where a lot of these PRs will come from) and reviewers alike, as Adrian points out in the "post-merge" peer review discussion above. Overall I can't see what the real benefits of this change are. Unless it really is official OpenWRT policy to release these as generic firmware tools for use by other projects, and it absolutely has to be a separate git repo. On many levels that's a good idea but also nebulous. E.g. for the xiaomifw vacuum example, why not put it in its own seperate upstream repo. Anyway, maybe people disagree and are OK with this. At a minimum to finish out this package split, someone needs to do this? * Create a GitHub mirror for https://git.openwrt.org/project/firmware-utils.git To avoid chaos in the future (or even now with 22.03, bugfixes, backports etc): * Release branches for "firmware-utils.git" matching "openwrt.git" (unless some versioning strategy like SEMVER is planned, but the OpenWRT release branches seem the simplest) Thanks, - Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Patch: ath79: Move TPLink WPA8630Pv2 to tiny target
https://github.com/openwrt/openwrt/pull/4500#issuecomment-1090822176 Old patch that may not be visible on the recent PRs. > These devices only have 6MiB available for firmware, > which is not enough for recent release images, so > move these to the tiny target. Tested by others and reviewed, should be ready for commit. Thanks in advance. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Seperating firmware-utils into seperate repo
Hi, firmware-utils was separated from openwrt.git into its own repository a few months ago: https://git.openwrt.org/?p=project/firmware-utils.git https://github.com/openwrt/openwrt/commit/8cc9a74a3f6bf363645efda6db417f8dadd3d844 If it's going to stay separate, it looks like these changes are still needed? - Release branches matching the main openwrt.git repo. (E.g. To facilitate firmware bugfixes on older OpenWRT release after any tool APIs in /master have changed) - A GitHub mirror (like everything here https://openwrt.org/submitting-patches ) - Update the developer guide with a workflow for adding and testing a new device involving changes to firmware-utils.git and openwrt.git. (This is tricky. When recently adding a new device, I built the changes in openwrt.git once, then manually rebuilt an updated firmware-util binary, then rebuilt the openwrt.git firmware image. Is there a proper building the main package and changes to package repos at the same time? There is also the can of worms w.r.t. people submitting changes and testing, likely it will need to be handled with 2 concurrent Pull Requests kept open until everything is 100% ready, in addition to the committers bump of the firmware-utils dependency). Possibly, but involves a lot of work and complexity: - Separating the per-device configuration from the C code into CLI arguments for the image Makefiles (or json files?), so that most new devices involving them can go back to being added with one atomic commit to openwrt.git. (see list below, and caveat) Re: Splitting firmware-utils out so it can be consumed by non-OpenWRT projects * This seems like the only practical benefit? Specifically, that this folder can now be consumed directly as a git submodule or package by another project, instead of copying from openwrt.git/tools/firmware-utils like in this existing example: https://www.freshports.org/devel/firmware-utils/ https://www.transit.hanse.de/mirror/svn.openwrt.org/firmware-utils/ * Vending to 3rd parties implies having a versioning policy to keep the API stable for all tools after branching from /master to release branches (i.e. API changes only allowed in /master, and the repo release branches would be equivalent to Semantic Versioning major releases). (The planned image tests would also cover this) * Also, will it decrease the benefit to 3rd parties if all the model-specific image configuration was separated from these tools and put back into openwrt.git, and how much of that config should stay in one repo or the other? Re: Splitting firmware-utils out so it can be covered under CI/CD tests * Is there a technical reason for this? (e.g. why not re-run tests on every openwrt.git commit, or just on changes to openwrt.git/tools/firmware-utils ?) Re: Seperating the per-device parameters (openwrt.git) from the base firmware tool (firmware-utils.git) * These are the affected files: addpattern.c avm-wasp-checksum.c iptime-crc32.c iptime-naspkg.c mkcasfw.c mkcsysimg.c mkfwimage.c mkheader_gemtek.c mkmerakifw.c mkmerakifw-old.c mkmylofw.c mkplanexfw.c mkporayfw.c mktplinkfw2.c mkzcfw.c mkzynfw.c motorola-bin.c tplink-safeloader.c xiaomifw.c zynos.h Overall, it seems debatable as to whether this particular package should be split out, or stay in the main repo like before with the rest of the per-device configuration. Cheers, - Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ucidef_set_led_netdev port_mask equivilant for DSA?
Hi, I'm working on a DSA device where the OEM behaviour has 1 Ethernet LED show the state of 3 Ethernet switch ports (and is off when none of them are active). It looks like "ucidef_set_led_netdev" is the main way of setting LEDs for DSA switches. Is there an equivilant for the "port_mask" argument of "ucidef_set_led_switch"? I think most DSA devices have seperate lan1,lan2,lan3,lan4 LEDs so this may not have come up before. Compared to "swconfig_leds.c", it looks like the upstream "ledtrig-netdev.c" can only monitor one device at a time. Otherwise, the fallback is this, which means an always-on LED, and it blinks when there is also WiFi activity. Not the end of the world, just curious if this has been solved already. ucidef_set_led_netdev "lan" "LAN" "green:lan" "br-lan" Thanks! - Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Custom DTS / DTB building with ImageBuilder
Great, it turns out to be very straightforward. To build a DTS into DTB and assemble the firmware kernel image using the Image Builder Makefile recipes, you just need to manually invoke the built target for it. You'll also need to fetch any missing DTS header dependencies it complains about. Then you can build the image as normal. ln -sf /usr/bin/cpp staging_dir/host/bin/mips-openwrt-linux-musl-cpp PATH=$(pwd)/staging_dir/host/bin:$PATH make --trace -C target/linux/ath79/image "$(pwd)/build_dir/target-mips_24kc_musl/linux-ath79_generic/tplink_archer-c7-v5-kernel.bin" TOPDIR="$(pwd)" INCLUDE_DIR="$(pwd)/include" TARGET_BUILD=1 BOARD="ath79" SUBTARGET="generic" PROFILE="tplink_archer-c7-v5" DEVICE_DTS="qca9563_tplink_archer-c7-v5" make image PROFILE="tplink_archer-c7-v5" Full example which patches in a new custom device profile and builds it: [1] https://github.com/jwmullally/openwrt_wpa8630p_v2_fullmem/blob/master/Makefile On Sat, Feb 27, 2021 at 12:21 AM Joseph Mullally wrote: > > Hi, > > Device Tree is great as it decouples the hardware layout from the > kernel build. What are peoples thoughts on supporting custom DTS > building in ImageBuilder? There are a few advantages: Uses the > official kernel, makes it easier to support out-of-tree unofficial > firmwares etc. [1] says DTS files were rebuilt in Chaos Calmer Image > Builder? > > As an example: https://github.com/jwmullally/openwrt_wpa8630p_v2_fullmem > > As you can see from the Makefile, most of the tools are already > included in ImageBuilder except for cpp and some DTS headers from the > kernel (ignore the tplink-firmware.c patching as its unavoidable). > There are some clunky parts there, like needing to manually assemble > the "-kernel.bin" instead of using the OpenWRT Makefile definitions. > Does anyone know how to do that? I got close using "make -C > target/linux/ath79/image install" with "IB" undefined, but I wasn't > able to narrow it down enough to build just one DTB + image for a > single profile. That would probably solve most of the issue and make > these out-of-tree builds much simpler. > > Other examples from the forums: > [1] https://forum.openwrt.org/t/dts-support-in-imagebuilder/12320 > [2] https://forum.openwrt.org/t/ath79-dtb-update-mechanism/52630 > [3] > https://forum.openwrt.org/t/using-release-ath79-19-07-0-kernel-and-packages-on-hardware-modded-tp-link-wr703n-16mb-64mb-without-snapshot-compilation/54310 > > Thanks > - Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Custom DTS / DTB building with ImageBuilder
Hi, Device Tree is great as it decouples the hardware layout from the kernel build. What are peoples thoughts on supporting custom DTS building in ImageBuilder? There are a few advantages: Uses the official kernel, makes it easier to support out-of-tree unofficial firmwares etc. [1] says DTS files were rebuilt in Chaos Calmer Image Builder? As an example: https://github.com/jwmullally/openwrt_wpa8630p_v2_fullmem As you can see from the Makefile, most of the tools are already included in ImageBuilder except for cpp and some DTS headers from the kernel (ignore the tplink-firmware.c patching as its unavoidable). There are some clunky parts there, like needing to manually assemble the "-kernel.bin" instead of using the OpenWRT Makefile definitions. Does anyone know how to do that? I got close using "make -C target/linux/ath79/image install" with "IB" undefined, but I wasn't able to narrow it down enough to build just one DTB + image for a single profile. That would probably solve most of the issue and make these out-of-tree builds much simpler. Other examples from the forums: [1] https://forum.openwrt.org/t/dts-support-in-imagebuilder/12320 [2] https://forum.openwrt.org/t/ath79-dtb-update-mechanism/52630 [3] https://forum.openwrt.org/t/using-release-ath79-19-07-0-kernel-and-packages-on-hardware-modded-tp-link-wr703n-16mb-64mb-without-snapshot-compilation/54310 Thanks - Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
