00:01 <chewitt> tuxd3v these patches will be needed for PCIe https://patchwork.ozlabs.org/project/uboot/list/?series=235860

00:03 <chewitt> also see https://github.com/superna9999/u-boot/commits/u-boot/topic/amlogic-pcie

00:05 <chewitt> the patchwork patches are newer but stops short of enabling everything on VIM3, while the github branch has those bits (but older patches AFAICT)

00:06 <chewitt> the patchwork series is RFT so let @narmstrong know if it works or not :)

00:09 <narmstrong> Yes we can boot from NVMe ! Haven’t tried further than reading and writing from the disk, everything must work fine. Bonus: you can also share the NVMe as mass storage which is cool !

12:57 <hexdump01> looks like i'm seeing problems with later v5.10 kernels - as soon i a startup xorg with lima the system hangs

12:58 <hexdump01> system=mi-box gxl which has secure boot and in dmesg i see: " OF: fdt: Reserved memory: failed to reserve memory for node 'hwrom@0': base 0x0000000000000000, size 16 MiB"

12:58 <hexdump01> and "OF: fdt: Reserved memory: failed to reserve memory for node 'secmon@05000000': base 0x0000000005000000, size 3 MiB"

12:59 <hexdump01> looks like kernel-ci has seen this too on recent backported kernels: https://storage.kernelci.org/stable-rc/linux-4.14.y/v4.14.226/arm64/defconfig/gcc-8/lab-baylibre/baseline-meson-gxm-q200.html

13:00 <hexdump01> v5.10.1 is working fine for me - my guess is that maybe something is wrong with the mem reservation and the kernel tries to allocate into secmon which does not really likes that and results in a hanging system

13:00 <hexdump01> any ideas anyone? any suspect recent changes?

13:02 <hexdump01> with v5.10.1 the mem reservation error is not there btw.

13:10 <chewitt> hexdump01 - I've seen it on a few boards/boots but it's not prevented me from booting devices

13:11 <chewitt> e.g. OF: fdt: Reserved memory: failed to reserve memory for node 'secmon@5000000': base 0x0000000005000000, size 3 MiB

13:11 <chewitt> ^ from an N2+ on 5.12-rc4

13:12 <chewitt> no ideas on the cause, I've pinged @narmstrong on this a few weeks ago and oddly .. about 5 mins ago too :)

13:16 <chewitt> I see the same messages as you on a GXBB device; but lima is loaded and Kodi is running so it's not affecting boot for me

13:20 <hexdump01> chewitt: i guess it is not problem on your boxes, because they are not using the secure memory ... this box with secure boot is using it and thus runs into trouble

13:21 <hexdump01> i guess that the reservations for whatever reason seem to really fail - in your case without any harm and in my case its not that harmless :)

13:21 <chewitt> hexdump01 I also have this in my tree https://github.com/chewitt/linux/commit/08098e84ffcdc82308efb2918450a80576827f1b

13:33 <hexdump01> chewitt: i have only two secmon regions defined in both the working v5.10.1 and the non working v5.10.25 dtb, so i guess its not that definition but more the code which does the reservations which changed

17:33 <narmstrong> Is this with mainline uboot ?

17:33 <narmstrong> Mainline uboot also adds this memory region ad fdt reserved memory, until now there was no conflicts but maybe something has changed

18:47 <hexdump01> narmstrong: no this is with legacy u-boot - i cannot put mainline u-boot onto this thing as the boot block is crypted and i do not have they key and do not even now how to encrapt it properly

18:48 <hexdump01> narmstrong: and it is working perfectly fine with v5.10.1, so something must have changed - worst case i can try to bisect it, but i would prefer to avoid this as its a pain to always build kernels and boot them to find out ...