On Fri, Mar 10, 2023 at 2:21 AM Petr Štetiar <[email protected]> wrote: > > Tim Harvey <[email protected]> [2023-03-09 12:19:24]: > > Hi, > > > Is there any reason to move them into target/linux/generic/backport-5.15? > > sorry for confusing you, but I've just meant to rename the patch files itself, > so they contain bacported kernel version in their filename, making the patch > origin explicit as it makes maintenance of the patches much easier. > > There is no need to move it into generic kernel folder and complicate stuff > there. > > > I'm assuming you mean just add details above on how I'm booting in the > > commit message? > > Yes, just imagine someone buying your board, without much prior knowledge and > would use the commit message as the only source for booting that board with > OpenWrt. > > BTW for the folks handling the wiki, the commit message is usually the only > source of information. > > > The reason right now that I'm avoiding boot firmware is: > > 1. There was pushback regarding the firmware-imx-8.15.bin license > > required to build boot firmware (see > > http://lists.openwrt.org/pipermail/openwrt-devel/2022-August/039247.html) > > Well, IMO its crystal clear, that NXP needs to fix this, we can't do much > about it, unless you plan to host it on your servers :-) > > Anyway, it's clear, that there is some interest in this SoC and it would be > helpful to have some common base for development, even in the source-only > form. > > Thus I would simply like to merge partial support for this SoC once 23.y is > branched, unless of course NACKed. Its really against FOSS spirit, we > shouldn't promote such SoCs even in the source-only form, but I sincerely > hope, that NXP is going to understand the situation and fix it before next > OpenWrt release.
if I address your feedback and post a v2 must it wait until after 23.y branch based on the minimal impact to the imx target? > > If it turns out, that I was very naive, we should probably cast a vote and > either keep it in source-only form or remove it. > > > This is due FEATURES having ubifs causing USES_UBIFS and > > TARGET_ROOTFS_UBIFS getting set but because > > IMO this is likely due to a fact, that you've not defined any device in your > image file, so you don't define `FILESYSTEMS` variable and thus the build > system uses default `TARGET_FILESYSTEMS` which has `ubifs` defined. > True... from include/image/mk: fs-types-$(CONFIG_TARGET_ROOTFS_UBIFS) += ubifs ... TARGET_FILESYSTEMS := $(fs-types-y) The failure is trying to copy the root.ubifs during image copy: cp /usr/src/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-imx_cortexa53/root.ubifs /usr/src/openwrt/openwrt/bin/targets/imx/cortexa53/openwrt-imx-cortexa53-ubifs.img cp: cannot stat '/usr/src/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-imx_cortexa53/root.ubifs': No such file or directory > So I would probably try to just define a support for a single device with > empty FILESYSTEMS variable and see how that works. Adding a FILESYSTEMS:= by itself in image/cortexa53.mk still fails Adding the following doesn't seem to help either (I don't think this does anything without something being in TARGET_DEVICES) define Device/Default KERNEL_NAME := Image KERNEL := kernel-bin DTS_DIR := $(LINUX_DIR)/arch/$(LINUX_KARCH)/boot/dts/freescale FILESYSTEMS := squashfs ext4 endef And adding an actual device and building for it still fails define Device/Default KERNEL_NAME := Image KERNEL := kernel-bin DTS_DIR := $(LINUX_DIR)/arch/$(LINUX_KARCH)/boot/dts/freescale FILESYSTEMS := squashfs ext4 endef define Device/rootfs_emmc $(call Device/Default) DEVICE_VARIANT := eMMC rootfs FILESYSTEMS := endef TARGET_DEVICES += rootfs_emmc Perhaps I'm doing something wrong above? Perhaps its just fine moving ubifs from target/linux/imx/Makefile to the cortexa7/cortexa9 subtargets until someone finds the need for ubifs in a specific device? Thanks, Tim _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
