[PATCH] procd: Adding support to detect Pantavisor Container Platform
Hi John, I missed your message, seems like it didn't land in inbox or spam folder of my e-mail. > as it runs a custom modified version > of LXC > I assume that if this is a custom downstream version then the change is > not applicable for merge into upstream owrt. please explain what "custom > version" means. > John Actually, we don't use a custom version of lxc, we use the upstream stable lxc. The reason for this patch is that the hardcoded mount of /dev prevents our way of usage of openwrt in containers. - Gaurav ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] procd: Adding support to detect Pantavisor Container Platform
On Mon, Mar 22, 2021 at 03:38:25PM +0530, Gaurav Pathak wrote: > Hi John, > > I missed your message, seems like it didn't land in inbox or spam folder of > my e-mail. > > > as it runs a custom modified version > > of LXC > > > I assume that if this is a custom downstream version then the change > is > > not applicable for merge into upstream owrt. please explain what > "custom > > version" means. > > > John > > Actually, we don't use a custom version of lxc, we use the upstream stable > lxc. > The reason for this patch is that the hardcoded mount of /dev prevents our > way of usage of openwrt in containers. In that case I believe the best is to revert the patch which applies a Pantavisor-specific hack to detect if running inside a container and switch to a method which works for all users of LXC equally (like it is has already been done for Docker, see container.h in procd sources). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] procd: Adding support to detect Pantavisor Container Platform
On Mon, Mar 22, 2021 at 10:42:25AM +, Daniel Golle wrote: > On Mon, Mar 22, 2021 at 03:38:25PM +0530, Gaurav Pathak wrote: > > Hi John, > > > > I missed your message, seems like it didn't land in inbox or spam folder of > > my e-mail. > > > > > as it runs a custom modified version > > > of LXC > > > > > I assume that if this is a custom downstream version then the change > > is > > > not applicable for merge into upstream owrt. please explain what > > "custom > > > version" means. > > > > > John > > > > Actually, we don't use a custom version of lxc, we use the upstream stable > > lxc. > > The reason for this patch is that the hardcoded mount of /dev prevents our > > way of usage of openwrt in containers. > > In that case I believe the best is to revert the patch which applies a > Pantavisor-specific hack to detect if running inside a container and > switch to a method which works for all users of LXC equally (like it > is has already been done for Docker, see container.h in procd sources). > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel We tried to use the existing implementation that is in is_container() without any modification, but the key difference is that we use a container to run a full system container rather than just a "normal" app container, the current logic is correct when we use openwrt as an app container in our lxc based pantavisor, but it will do too much for the containers on our system that are suppose to run like the "main OS", like our pv-root plaforms. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] procd: Adding support to detect Pantavisor Container Platform
On Mon, Mar 22, 2021 at 05:00:06PM +0530, Gaurav Pathak wrote: > On Mon, Mar 22, 2021 at 10:42:25AM +, Daniel Golle wrote: > > On Mon, Mar 22, 2021 at 03:38:25PM +0530, Gaurav Pathak wrote: > > > > I assume that if this is a custom downstream version then the change > > > is > > > > not applicable for merge into upstream owrt. please explain what > > > "custom > > > > version" means. > > > > > > Actually, we don't use a custom version of lxc, we use the upstream > > > stable lxc. > > > The reason for this patch is that the hardcoded mount of /dev prevents > > > our way of usage of openwrt in containers. > > > > In that case I believe the best is to revert the patch which applies a > > Pantavisor-specific hack to detect if running inside a container and > > switch to a method which works for all users of LXC equally (like it > > is has already been done for Docker, see container.h in procd sources). > > > We tried to use the existing implementation that is in is_container() without > any modification, > but the key difference is that we use a container to run a full system > container rather than just a "normal" app container, > the current logic is correct when we use openwrt as an app container in our > lxc based pantavisor, > but it will do too much for the containers on our system that are suppose to > run like the "main OS", like our pv-root plaforms. The logic in container.h is made for exactly that (ie. full-system container rather than App container). If you are using unmodified LXC this should work without problems as LXC sets an environment variabel (container=lxc) and we do detect the presence of that environment variable in container.h. Hence the easiest way would be you just use that existing mechanism (ie. just go with LXC defaults which do set that env variable) as that would not require any Pantavisor-specific hacks in our codebase. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: artifacts add dependency for builded images
Hi, On 21.3.2021 11.55, Paul Spooren wrote: On Sat Mar 20, 2021 at 10:58 PM HST, Oskari Lemmela wrote: Add possibility to use images and initramfs in artifacts. Signed-off-by: Oskari Lemmela --- Hi, could you please elaborate on your use-case? One use case is build full sdcard image for Bananapi R64. Currently fit and initramfs images need to be copied over tftp/serial after booting from sdcard. Oskari include/image.mk | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/image.mk b/include/image.mk index 29df0938bc..8b7b2b9740 100644 --- a/include/image.mk +++ b/include/image.mk @@ -478,6 +478,7 @@ define Device/Build/initramfs $$(if $$(CONFIG_JSON_OVERVIEW_IMAGE_INFO), $(BUILD_DIR)/json_info_files/$$(KERNEL_INITRAMFS_IMAGE).json,)) $(KDIR)/$$(KERNEL_INITRAMFS_NAME):: image_prepare + $(1)-images: $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE) $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE): $(KDIR)/tmp/$$(KERNEL_INITRAMFS_IMAGE) cp $$^ $$@ @@ -570,6 +571,7 @@ define Device/Build/image $(BUILD_DIR)/json_info_files/$(call DEVICE_IMG_NAME,$(1),$(2)).json, \ $(BIN_DIR)/$(call DEVICE_IMG_NAME,$(1),$(2))$$(GZ_SUFFIX)) $(eval $(call Device/Export,$(KDIR)/tmp/$(call DEVICE_IMG_NAME,$(1),$(2)),$(1))) + $(3)-images: $(BIN_DIR)/$(call DEVICE_IMG_NAME,$(1),$(2))$$(GZ_SUFFIX) ROOTFS/$(1)/$(3) := \ $(KDIR)/root.$(1)$$(strip \ @@ -628,7 +630,7 @@ endef define Device/Build/artifact $$(_TARGET): $(BIN_DIR)/$(DEVICE_IMG_PREFIX)-$(1) $(eval $(call Device/Export,$(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1))) - $(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1): $$(KDIR_KERNEL_IMAGE) + $(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1): $$(KDIR_KERNEL_IMAGE) $(2)-images @rm -f $$@ $$(call concat_cmd,$(ARTIFACT/$(1))) @@ -651,7 +653,7 @@ define Device/Build $$(call Device/Build/image,$$(fs),$$(image),$(1) $$(eval $$(foreach artifact,$$(ARTIFACTS), \ - $$(call Device/Build/artifact,$$(artifact + $$(call Device/Build/artifact,$$(artifact),$(1 endef -- 2.25.1 ___ 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] build: artifacts add dependency for builded images
On Mon, Mar 22, 2021 at 04:44:47PM +0200, Oskari Lemmelä wrote: > Hi, > > On 21.3.2021 11.55, Paul Spooren wrote: > > On Sat Mar 20, 2021 at 10:58 PM HST, Oskari Lemmela wrote: > > > Add possibility to use images and initramfs in artifacts. > > > > > > Signed-off-by: Oskari Lemmela > > > --- > > Hi, could you please elaborate on your use-case? > > One use case is build full sdcard image for Bananapi R64. > > Currently fit and initramfs images need to be copied over > tftp/serial after booting from sdcard. You can also just append the initramfs to the sdcard image, btw. With these changes things will become easier and more accessible to users who don't know how to use 'dd'. Are you planning to also post a patch to make use of this change to generate a full SD card image (ie. incl. initramfs as well as sysupgrade image)? Cheers Daniel > > Oskari > > > > > > include/image.mk | 6 -- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/include/image.mk b/include/image.mk > > > index 29df0938bc..8b7b2b9740 100644 > > > --- a/include/image.mk > > > +++ b/include/image.mk > > > @@ -478,6 +478,7 @@ define Device/Build/initramfs > > > $$(if $$(CONFIG_JSON_OVERVIEW_IMAGE_INFO), > > > $(BUILD_DIR)/json_info_files/$$(KERNEL_INITRAMFS_IMAGE).json,)) > > > $(KDIR)/$$(KERNEL_INITRAMFS_NAME):: image_prepare > > > + $(1)-images: $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE) > > > $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE): > > > $(KDIR)/tmp/$$(KERNEL_INITRAMFS_IMAGE) > > > cp $$^ $$@ > > > @@ -570,6 +571,7 @@ define Device/Build/image > > > $(BUILD_DIR)/json_info_files/$(call DEVICE_IMG_NAME,$(1),$(2)).json, \ > > > $(BIN_DIR)/$(call DEVICE_IMG_NAME,$(1),$(2))$$(GZ_SUFFIX)) > > > $(eval $(call Device/Export,$(KDIR)/tmp/$(call > > > DEVICE_IMG_NAME,$(1),$(2)),$(1))) > > > + $(3)-images: $(BIN_DIR)/$(call DEVICE_IMG_NAME,$(1),$(2))$$(GZ_SUFFIX) > > > ROOTFS/$(1)/$(3) := \ > > > $(KDIR)/root.$(1)$$(strip \ > > > @@ -628,7 +630,7 @@ endef > > > define Device/Build/artifact > > > $$(_TARGET): $(BIN_DIR)/$(DEVICE_IMG_PREFIX)-$(1) > > > $(eval $(call Device/Export,$(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1))) > > > - $(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1): $$(KDIR_KERNEL_IMAGE) > > > + $(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1): $$(KDIR_KERNEL_IMAGE) > > > $(2)-images > > > @rm -f $$@ > > > $$(call concat_cmd,$(ARTIFACT/$(1))) > > > @@ -651,7 +653,7 @@ define Device/Build > > > $$(call Device/Build/image,$$(fs),$$(image),$(1) > > > $$(eval $$(foreach artifact,$$(ARTIFACTS), \ > > > - $$(call Device/Build/artifact,$$(artifact > > > + $$(call Device/Build/artifact,$$(artifact),$(1 > > > endef > > > -- > > > 2.25.1 > > > > > > > > > ___ > > > 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] mwlwifi: remove target dependency
Hi Daniel, FWIW in my opinion we should get back to this topic as soon as you have a mwlwifi supported card up and running on any other platform. Right now this would introduce a change just to make a different platform's SDK usable for a purpose which would get a straight "no" from the developer community if a user would have proposed it. I'm against this change (not that it matters ever since you've stripped maintainer roles in the name of democracy). Imre From: Daniel Golle Sent: Sunday, March 21, 2021 22:17 To: openwrt-devel@lists.openwrt.org Cc: Imre Kaloz Subject: [PATCH] mwlwifi: remove target dependency Users complained that building images for various mvebu Linksys devices fails when using the ImageBuilder, it complains about the package 'mwlwifi-firmware-88w8964' not being found. Turns out the package builds fine in mvebu/cortex-a9 images build, but isn't built at all for arm/cortex-a9 packages. This is because we are using the SDK for bcm53xx/generic to build packages for arm/cortex-a9, hence the dependency for @TARGET_mvebu fails. Remove the target dependency as kmod-mwlwifi as well as firmware packages actually build fine on all platforms (and people might even want to use Marvell mPCIe Wifi on non-mvebu platforms). As a result, the missing 'mwlwifi-firmware-'* packages should become available for arm/cortex-a9 (and all other platforms). Signed-off-by: Daniel Golle --- See also: https://forum.openwrt.org/t/recent-imagebuilder-build-issues-for-wrt3200acm-on-master/91802 package/kernel/mwlwifi/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/kernel/mwlwifi/Makefile b/package/kernel/mwlwifi/Makefile index 648c826ccb..14973d0010 100644 --- a/package/kernel/mwlwifi/Makefile +++ b/package/kernel/mwlwifi/Makefile @@ -28,7 +28,7 @@ include $(INCLUDE_DIR)/package.mk define KernelPackage/mwlwifi SUBMENU:=Wireless Drivers TITLE:=Marvell 88W8864/88W8897/88W8964/88W8997 wireless driver - DEPENDS:=+kmod-mac80211 +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT @PCI_SUPPORT @TARGET_mvebu + DEPENDS:=+kmod-mac80211 +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT @PCI_SUPPORT FILES:=$(PKG_BUILD_DIR)/mwlwifi.ko AUTOLOAD:=$(call AutoLoad,50,mwlwifi) endef @@ -54,7 +54,7 @@ define Package/mwlwifi-firmware-default SECTION:=firmware CATEGORY:=Firmware TITLE:=Marvell $(1) firmware - DEPENDS:=+kmod-mwlwifi @TARGET_mvebu + DEPENDS:=+kmod-mwlwifi endef define Package/mwlwifi-firmware/install -- 2.31.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] procd: Adding support to detect Pantavisor Container Platform
On Mon, Mar 22, 2021 at 11:53:35AM +, Daniel Golle wrote: > On Mon, Mar 22, 2021 at 05:00:06PM +0530, Gaurav Pathak wrote: > > On Mon, Mar 22, 2021 at 10:42:25AM +, Daniel Golle wrote: > > > On Mon, Mar 22, 2021 at 03:38:25PM +0530, Gaurav Pathak wrote: > > > > > I assume that if this is a custom downstream version then the > > > > change is > > > > > not applicable for merge into upstream owrt. please explain > > > > what "custom > > > > > version" means. > > > > > > > > Actually, we don't use a custom version of lxc, we use the upstream > > > > stable lxc. > > > > The reason for this patch is that the hardcoded mount of /dev prevents > > > > our way of usage of openwrt in containers. > > > > > > In that case I believe the best is to revert the patch which applies a > > > Pantavisor-specific hack to detect if running inside a container and > > > switch to a method which works for all users of LXC equally (like it > > > is has already been done for Docker, see container.h in procd sources). > > > > > We tried to use the existing implementation that is in is_container() > > without any modification, > > but the key difference is that we use a container to run a full system > > container rather than just a "normal" app container, > > the current logic is correct when we use openwrt as an app container in our > > lxc based pantavisor, > > but it will do too much for the containers on our system that are suppose > > to run like the "main OS", like our pv-root plaforms. > > The logic in container.h is made for exactly that (ie. full-system > container rather than App container). If you are using unmodified LXC > this should work without problems as LXC sets an environment variabel > (container=lxc) and we do detect the presence of that environment > variable in container.h. > > Hence the easiest way would be you just use that existing mechanism > (ie. just go with LXC defaults which do set that env variable) as that > would not require any Pantavisor-specific hacks in our codebase. I agree, but the thing is, we have a custom "init" called pantavisor, which is responsible for spawning different containers. We treat containers running at root level different than containers running at application level (fully privileged and unprivileged). We provide control to the platform inside container running at root level to become host OS (as main OS, OpenWRT in our case) but want the LXC to do the mounting and not the Platform itself. So, pantavisor (init) ignores "container=lxc" environment for the root (fully privileged) container but passes that environment to the containers running at application level. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mwlwifi: remove target dependency
On Mon, Mar 22, 2021 at 03:22:25PM +, Imre Kaloz wrote: > Hi Daniel, > > FWIW in my opinion we should get back to this topic as soon as you have a > mwlwifi supported card up and running on any other platform. Right now this > would introduce a change just to make a different platform's SDK usable for a > purpose which would get a straight "no" from the developer community if a > user would have proposed it. > This change makes mwlwifi usable also on mvebu. I does not right now, people fail to build images for e.g. WRT3200ACM using the ImageBuilder, see link to forums below as well as commit description. > I'm against this change (not that it matters ever since you've stripped > maintainer roles in the name of democracy). Do you have another idea then how we can get the issue resolved? (I prefer not having to make any changes on the buildbots) As you are the author of the driver, your opinion sure does matter, and I do see you as being responsible for it even if that fact is not reflected technically in the form of access control rules as it used to be before 2017. I could have obviously just commited that (rather trivial) change, but I thought it might be good to reach out and see if anyone has objections (because you wouldn't add dependencies just for the modest amount of fun in doing so, usually) Cheers Daniel > > > Imre > > > From: Daniel Golle > Sent: Sunday, March 21, 2021 22:17 > To: openwrt-devel@lists.openwrt.org > Cc: Imre Kaloz > Subject: [PATCH] mwlwifi: remove target dependency > > Users complained that building images for various mvebu Linksys devices > fails when using the ImageBuilder, it complains about the package > 'mwlwifi-firmware-88w8964' not being found. > > Turns out the package builds fine in mvebu/cortex-a9 images build, but > isn't built at all for arm/cortex-a9 packages. This is because we are > using the SDK for bcm53xx/generic to build packages for arm/cortex-a9, > hence the dependency for @TARGET_mvebu fails. > > Remove the target dependency as kmod-mwlwifi as well as firmware > packages actually build fine on all platforms (and people might even > want to use Marvell mPCIe Wifi on non-mvebu platforms). > As a result, the missing 'mwlwifi-firmware-'* packages should become > available for arm/cortex-a9 (and all other platforms). > > Signed-off-by: Daniel Golle > --- > See also: > https://forum.openwrt.org/t/recent-imagebuilder-build-issues-for-wrt3200acm-on-master/91802 > > package/kernel/mwlwifi/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/package/kernel/mwlwifi/Makefile b/package/kernel/mwlwifi/Makefile > index 648c826ccb..14973d0010 100644 > --- a/package/kernel/mwlwifi/Makefile > +++ b/package/kernel/mwlwifi/Makefile > @@ -28,7 +28,7 @@ include $(INCLUDE_DIR)/package.mk > define KernelPackage/mwlwifi >SUBMENU:=Wireless Drivers >TITLE:=Marvell 88W8864/88W8897/88W8964/88W8997 wireless driver > - DEPENDS:=+kmod-mac80211 +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT > @PCI_SUPPORT @TARGET_mvebu > + DEPENDS:=+kmod-mac80211 +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT > @PCI_SUPPORT >FILES:=$(PKG_BUILD_DIR)/mwlwifi.ko >AUTOLOAD:=$(call AutoLoad,50,mwlwifi) > endef > @@ -54,7 +54,7 @@ define Package/mwlwifi-firmware-default >SECTION:=firmware >CATEGORY:=Firmware >TITLE:=Marvell $(1) firmware > - DEPENDS:=+kmod-mwlwifi @TARGET_mvebu > + DEPENDS:=+kmod-mwlwifi > endef > > define Package/mwlwifi-firmware/install > -- > 2.31.0 > > > ___ > 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] procd: Adding support to detect Pantavisor Container Platform
On Mon, Mar 22, 2021 at 09:09:03PM +0530, Gaurav Pathak wrote: > On Mon, Mar 22, 2021 at 11:53:35AM +, Daniel Golle wrote: > > On Mon, Mar 22, 2021 at 05:00:06PM +0530, Gaurav Pathak wrote: > > > On Mon, Mar 22, 2021 at 10:42:25AM +, Daniel Golle wrote: > > > > On Mon, Mar 22, 2021 at 03:38:25PM +0530, Gaurav Pathak wrote: > > > > > > I assume that if this is a custom downstream version then the > > > > > change is > > > > > > not applicable for merge into upstream owrt. please explain > > > > > what "custom > > > > > > version" means. > > > > > > > > > > Actually, we don't use a custom version of lxc, we use the upstream > > > > > stable lxc. > > > > > The reason for this patch is that the hardcoded mount of /dev > > > > > prevents our way of usage of openwrt in containers. > > > > > > > > In that case I believe the best is to revert the patch which applies a > > > > Pantavisor-specific hack to detect if running inside a container and > > > > switch to a method which works for all users of LXC equally (like it > > > > is has already been done for Docker, see container.h in procd sources). > > > > > > > We tried to use the existing implementation that is in is_container() > > > without any modification, > > > but the key difference is that we use a container to run a full system > > > container rather than just a "normal" app container, > > > the current logic is correct when we use openwrt as an app container in > > > our lxc based pantavisor, > > > but it will do too much for the containers on our system that are suppose > > > to run like the "main OS", like our pv-root plaforms. > > > > The logic in container.h is made for exactly that (ie. full-system > > container rather than App container). If you are using unmodified LXC > > this should work without problems as LXC sets an environment variabel > > (container=lxc) and we do detect the presence of that environment > > variable in container.h. > > > > Hence the easiest way would be you just use that existing mechanism > > (ie. just go with LXC defaults which do set that env variable) as that > > would not require any Pantavisor-specific hacks in our codebase. > > I agree, but the thing is, we have a custom "init" called pantavisor, which > is responsible for spawning different containers. > We treat containers running at root level different than containers running > at application level (fully privileged and unprivileged). > We provide control to the platform inside container running at root level to > become host OS (as main OS, OpenWRT in our case) but want > the LXC to do the mounting and not the Platform itself. So, pantavisor (init) > ignores "container=lxc" environment for the root (fully privileged) > container but passes that environment to the containers running at > application level. > Thank you for the detailed explenation. In this case, I think the solution we have in place now and which detects the presence of the '/pantavisor' file is probably the best we can do. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ath79: Fix for Mikrotik NAND bad blocks - testers needed
Hi, I'm working on restoring Mikrotik RB2011 support after ar71xx target was dropped after 19.07 release. While working on it, the problem with bad blocks and the issue of the current way of flashing kernel was also brought up. Right now, for Mikrotiks we use kernel2minor which generates a 4MiB YAFFS2 partition image holding the kernel binary. This method can't take NAND bad blocks in the kernel partition area into account, and if there are any, flashing fails and the device is usable only for RouterOS, because YAFFS2 support was removed from OpenWrt a few years ago. I was able to re-add YAFFS2 driver and limit it only to Mikrotik builds of ath79 target, and in my tests it properly mounts the kernel partition and replaces the kernel binary. However, I don't have a device with bad blocks in the kernel area so I can't confirm if it will properly handle them, although it should work unless the upstream driver (or Kconfig) is messed up. So now I'm looking for testers (and reviewers) who could test this change on the affected devices (with bad blocks) and NOR Mikrotiks. Also, a word from OpenWrt maintainers if this is the acceptable approach - there is not much choice, alternatives would be include porting U-Boot, a task with questionable chance of success for all Mikrotik boards, or waiting for a bootloader update from Mikrotik that would allow booting from UBIFS like on their ipq40xx boards, and that's also questionable. This approach restores YAFFS2 support for Mikrotik devices only, so if the driver loses upstream support in the future, it will affect the Mikrotik builds only, where NAND images are not built anyway since 9d96b6fb72. IMO, this is a reasonable method to restore full support for those devices (and allow the merge of RB2011 support) today, while they still have reasonable HW specs. And the Mikrotik subtarget could be further split into NOR and NAND defconfigs to limit the scope of this change to NAND only. My changes are in this pull request: https://github.com/openwrt/openwrt/pull/3729/commits Some previous discussion regarding the NAND problem can be found here: https://github.com/openwrt/openwrt/pull/3026#issuecomment-675005309 https://github.com/openwrt/openwrt/pull/3729#issuecomment-767657647 https://forum.openwrt.org/t/rb433-bad-sector-cannot-start-openwrt/71519/3 Regards, Danijel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mwlwifi: remove target dependency
On 3/21/21 10:17 PM, Daniel Golle wrote: Users complained that building images for various mvebu Linksys devices fails when using the ImageBuilder, it complains about the package 'mwlwifi-firmware-88w8964' not being found. Turns out the package builds fine in mvebu/cortex-a9 images build, but isn't built at all for arm/cortex-a9 packages. This is because we are using the SDK for bcm53xx/generic to build packages for arm/cortex-a9, hence the dependency for @TARGET_mvebu fails. Remove the target dependency as kmod-mwlwifi as well as firmware packages actually build fine on all platforms (and people might even want to use Marvell mPCIe Wifi on non-mvebu platforms). As a result, the missing 'mwlwifi-firmware-'* packages should become available for arm/cortex-a9 (and all other platforms). Does this happen for the kmod or only for the firmware package? If this only happens for the firmware package, does it help to add this to the package Makefile: PKG_FLAGS:=nonshared I think we only have this problems with the packages build by the 2. phase build bot which is shared between different targets with the same CPU. When we make it nonshared it should be build together with the target. We had a similar problems with the mtd package some time ago. We should check if there are more places with similar problem. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mwlwifi: remove target dependency
On Mon, Mar 22, 2021 at 11:14:39PM +0100, Hauke Mehrtens wrote: > On 3/21/21 10:17 PM, Daniel Golle wrote: > > Users complained that building images for various mvebu Linksys devices > > fails when using the ImageBuilder, it complains about the package > > 'mwlwifi-firmware-88w8964' not being found. > > > > Turns out the package builds fine in mvebu/cortex-a9 images build, but > > isn't built at all for arm/cortex-a9 packages. This is because we are > > using the SDK for bcm53xx/generic to build packages for arm/cortex-a9, > > hence the dependency for @TARGET_mvebu fails. > > > > Remove the target dependency as kmod-mwlwifi as well as firmware > > packages actually build fine on all platforms (and people might even > > want to use Marvell mPCIe Wifi on non-mvebu platforms). > > As a result, the missing 'mwlwifi-firmware-'* packages should become > > available for arm/cortex-a9 (and all other platforms). > > Does this happen for the kmod or only for the firmware package? If this only > happens for the firmware package, does it help to add this to the package > Makefile: > PKG_FLAGS:=nonshared It's only the firmware package missing as the kmods are built in phase1. > > I think we only have this problems with the packages build by the 2. phase > build bot which is shared between different targets with the same CPU. When > we make it nonshared it should be build together with the target. We had a > similar problems with the mtd package some time ago. Yes, adding PKG_FLAGS:=nonshared would solve the problem (and shouldn't affect the anyway nonshared kmod build in the same package Makefile). I forgot about that one... > > We should check if there are more places with similar problem. Other potentially affected packages which do have target dependencies set but do not have PKG_FLAGS:=nonshared set: network/utils/ltq-dsl-base firmware/cypress-nvram All other non-kmod core packages seem to have nonshared set in case they got target dependencies. Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mwlwifi: remove target dependency
On Di, Mär 23, 2021 at 00:17, Daniel Golle wrote: On Mon, Mar 22, 2021 at 11:14:39PM +0100, Hauke Mehrtens wrote: On 3/21/21 10:17 PM, Daniel Golle wrote: > Users complained that building images for various mvebu Linksys devices > fails when using the ImageBuilder, it complains about the package > 'mwlwifi-firmware-88w8964' not being found. > > Turns out the package builds fine in mvebu/cortex-a9 images build, but > isn't built at all for arm/cortex-a9 packages. This is because we are > using the SDK for bcm53xx/generic to build packages for arm/cortex-a9, > hence the dependency for @TARGET_mvebu fails. > > Remove the target dependency as kmod-mwlwifi as well as firmware > packages actually build fine on all platforms (and people might even > want to use Marvell mPCIe Wifi on non-mvebu platforms). > As a result, the missing 'mwlwifi-firmware-'* packages should become > available for arm/cortex-a9 (and all other platforms). Does this happen for the kmod or only for the firmware package? If this only happens for the firmware package, does it help to add this to the package Makefile: PKG_FLAGS:=nonshared It's only the firmware package missing as the kmods are built in phase1. I think we only have this problems with the packages build by the 2. phase build bot which is shared between different targets with the same CPU. When we make it nonshared it should be build together with the target. We had a similar problems with the mtd package some time ago. Yes, adding PKG_FLAGS:=nonshared would solve the problem (and shouldn't affect the anyway nonshared kmod build in the same package Makefile). I forgot about that one... We should check if there are more places with similar problem. Other potentially affected packages which do have target dependencies set but do not have PKG_FLAGS:=nonshared set: network/utils/ltq-dsl-base firmware/cypress-nvram Could you do a treewide fixup patch? All other non-kmod core packages seem to have nonshared set in case they got target dependencies. Cheers Daniel ___ 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: ath79: Fix for Mikrotik NAND bad blocks - testers needed
> So now I'm looking for testers (and reviewers) who could test this change on > the affected devices (with bad blocks) and NOR Mikrotiks. Also, a word from > OpenWrt maintainers if this is the acceptable approach - there is not much > choice, alternatives would be include porting U-Boot, a task with questionable > chance of success for all Mikrotik boards, or waiting for a bootloader update > from Mikrotik that would allow booting from UBIFS like on their ipq40xx > boards, > and that's also questionable. I have a few RB493G boards that will not boot OpenWrt due to the bad blocks problem. Might your work work with them? The amount of spares I have allows me to offer one to someone who might have hope of modifying OpenWrt so that they boot again. I would be willing to split shipping and charge no more than that (I am in the USA). Of course, I would also be interested in hearing if Danijel's YAFFS2 solution is acceptable to the OpenWrt folks. These boards are still decent hardware. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
