In D47290#1078402, @junchoon_dec.sakura.ne.jp wrote:

Updated my patch at Bug 282312 as rev3, chasing @manu's commit, for further reviews.
And this review (D47290) can now be closed as of:

commit f2a03a6a45607086a94ee1aa9b9b847b0734da6b
graphics/nvidia-drm-515-kmod: Bump version after drm-515-kmod update
https://cgit.freebsd.org/ports/commit/?id=f2a03a6a45607086a94ee1aa9b9b847b0734da6b

and

commit 2716dbb157611eaae6e578d86202d86910026562
graphics/nvidia-drm-61-kmod: Bump version after drm-61-kmod update
https://cgit.freebsd.org/ports/commit/?id=2716dbb157611eaae6e578d86202d86910026562

Thanks, @manu for commiting!

This also matches what netbsd did in https://github.com/NetBSD/src/commit/7322109ce6aebe447e07c038a5aedbb87c363649

Does TI upstream from time to time their patches or will it be a pain at each u-boot update ?

You need to add the new port to the category Makefile (same for your other reviews btw)

I think that for introducing OP-TEE to the ports tree we should go the master way a la u-boot/atf even if for now it only support TI.
Rockchip can be built with OP-TEE, I've never tested as it's not mandatory.

Wouldn't it be easier to have 3 different port (lite generic and J784S4) ?

Not sure this is worth it, people can have local modification if they want to work on TI stuff.
We know that the current code doesn't boot with latest dtb so until this is solved no point of adding this config.

In D46702#1064761, @imp wrote:

I thought we'd done this a while ago?

LGTM

LGTM

Don't forget to change commit message.

In D46532#1060977, @thj wrote:

In D46532#1060750, @manu wrote:

Any idea why it have a different compatible string ?
Is this because only of features that we don't use ?

I have no idea why they are adding more and more compat strings. imx8mq and imx8mp are very similar, but they don't seem to share compat in the dtsi files. There is some sharing with imx8mm.

Compat for gpio from imx8mp.dtsi is:

compatible = "fsl,imx8mp-gpio", "fsl,imx35-gpio";

Any idea why it have a different compatible string ?
Is this because only of features that we don't use ?
Have you tested interrupts ?

In D46287#1055758, @markj wrote:

In D46287#1055704, @manu wrote:

Mhm, that would mean that we need to buildworld before make create-kernel-packages which I think isn't needed right now as I used that in the past to dev only on kernel part. Could we use another file if uname isn't built yet ?

I'm not sure which file we could use. The kernel won't have an ABI note, so that doesn't work. kernel-toolchain outputs are compiled for the host system, not the target.

I thought packages and update-packages were the only top-level targets. And I'm not sure how your workflow worked before, there were uses of -o ABI_FILE=${WSTAGEDIR}/usr/bin/uname in the create-kernel-packages target above.

Mhm, that would mean that we need to buildworld before make create-kernel-packages which I think isn't needed right now as I used that in the past to dev only on kernel part. Could we use another file if uname isn't built yet ?

Reset libosmesa PORTREVISION

In D46224#1054164, @wulf wrote:

Both compiles and runs

I haven't tested yet but is it compatible with drm-515-kmod and drm-61-kmod ?

LGTM but I'm not a doc committer.

Add a stub for virtio_gpu