12:26 <montjoie> smaeul: thanks to your help, my nezha is progressing, but now I got INITRD: 0x417e2000+0x0161e000 is not a memory region - disabling initrd

12:26 <montjoie> I use booti 0x40040000 0x41C00000 0x44000000

13:58 <smaeul> montjoie: where did the devicetree at 0x44000000 come from? if it's not a copy of the one $fdtcontroladdr, it's wrong

13:59 <smaeul> also I think you may need the $addr:$size syntax for your initramfs if it's not wrapped in a U-Boot legacy image

14:00 <smaeul> (generally I would recommend using $fdtcontroladdr directly, unless you apply overlays)

14:01 <apritzel> also worth checking is if U-Boot is moving the initrd around: it should report saying so

14:02 <apritzel> smaeul: does U-Boot even allow this syntax without it being an uImage?

14:17 <smaeul> I don't think so?

14:19 <gamiee> https://i.imgur.com/4XntfrS.png allannals V3s ... :D

16:16 <montjoie> smaeul: initrd is a uboot image

16:29 <montjoie> with $fdtcontroladdr, I got TFTP error: trying to overwrite reserved memory...

16:37 <jernej> montjoie: $fdtcontroladdr already contains DTB, modified by firmware, so you shouldn't overwrite it

16:40 <montjoie> does modifying dtb will be available in the future ?

16:42 <montjoie> anyway with fdtcontroladdr, no bootlog:'(

16:43 <montjoie> probably because fdtcontroladdr does not have earlycon

16:50 <jernej> you should be able to set custom bootargs

16:50 <jernej> you can modify DT via overlays

16:51 <jernej> or patch U-Boot DT files and rebuild whole U-Boot

22:43 <smaeul> you call booti after finishing all of the TFTP transfers, so I don't see how changing the booti argument to $fdtcontroladdr could cause a TFTP error

22:45 <smaeul> you can also add earlycon with the bootargs environment variable, regardless of where the DT comes from

22:45 <smaeul> *modifying* the DTB, via an overlay or the `fdt` command, is supported. *replacing* it is not supported

22:52 <apritzel> smaeul: did you try applying overlays or changing with the fdt command at the original $fdtcontroladdr location?

22:53 <apritzel> I remember this worked a few years back, but doesn't work anymore, I guess U-Boot puts some data behind the image (and thus DTB)

22:53 <apritzel> at least on arm, don't know if this is different on D1

22:54 <smaeul> I think it's more that the DM holds offsets into the controll FDT if you don't have OF_LIVE enabled

22:54 <smaeul> and modifying the FDT can change these offsets

22:54 <apritzel> mmmh, possible, might check this

22:54 <smaeul> so trivial changes work, but not something like adding new nodes

22:55 <apritzel> anyway, a workaround seems to be to copy the DTB first

22:55 <smaeul> > However a flat tree does not support modification from within U-Boot since it can invalidate driver-model device tree offsets. This option enables a live tree which is available after relocation, and can be adjusted as needed.

22:55 <apritzel> ah, nice

22:56 <apritzel> so do those modifications affect U-Boot's operation then?

22:56 <apritzel> I guess this is probably not what most people want, instead they want to apply overlays or change nodes for the kernel

22:57 <apritzel> for that I use: "fdt move $fdtcontroladdr $fdt_addr_r"

22:57 <apritzel> then work on that address

22:58 <smaeul> right, $fdtcontroladdr is what U-Boot is actively using, if OF_LIVE=n

23:04 <apritzel> ah, so with OF_LIVE=y any changes to the DTB at $fdtcontroladdr wouldn't affect U-Boot anymore, because it's using a unflattened tree, somewhere else in memory