[PATCH] imx: add imx8 support

[Tim Harvey]

On Fri, Mar 10, 2023 at 2:21 AM Petr Štetiar <ynezz at true.cz> wrote:
>
> Tim Harvey <tharvey at gateworks.com> [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