08:55 <oldgalileo> Howdy! I'm a bit confused on the boot process and on where and when U-Boot gets the DTB

09:04 <oldgalileo> I'm working right now with the Nano P3448-0002. Taking a look at the partition layout, here's the flow as I understand it thus far:

09:08 <oldgalileo> U-Boot loads the U-Boot DTB from the RP1 partition. U-Boot then loads the Linux Kernel and passes it the kernel DTB from the DXB partition (?)

09:09 <oldgalileo> It's specifically the last part I'm unclear of.

09:13 <oldgalileo> https://www.denx.de/wiki/DULG/UBootCmdGroupExec

09:13 <oldgalileo> Per the `bootm` section, I'm still unclear on /where/ the kernel DTB addresss is.

09:14 <oldgalileo> The thing that's confusing me is that the DTB is written on the rootfs. I can't figure out why it would be BOTH in /boot/ AND in the DXB partition

09:39 <cyndis> I don't remember the details but I think it depends on how extlinux.conf is written and also it can use the partition as backup if the one in /boot is missing

09:40 <cyndis> although I haven't used the nano; only TX2 recently

09:41 <cyndis> the kernel dtb address is probably in u-boot environment variables

09:42 <cyndis> or maybe u-boot autogenerates it if using extlinux.conf flow

09:48 <oldgalileo> cyndis: I feel like I'm taking crazy pills. So U-Boot has a sysboot command which can understand filesystems. U-Boot executes sysboot to load extlinux, which then points U-Boot to the kernel image and the init ramdisk

09:49 <oldgalileo> You can optionally tell extlinux.conf to load a specific DTB with the FDT directive. That's all fine and good.

09:49 <oldgalileo> The part that _confounds_ me and explodes my brain, is what is the point of TegrabootCPU doing EMC training on the kernel dtb if it's never used?

09:50 <oldgalileo> TegrabootCPU definitely isn't filesystem aware, so it must be doing that training on the DXB partition where the kernel dtb data is stored.

09:50 <oldgalileo> I do not understand where in the boot process that kernel dtb information is ever actually used?

09:50 <oldgalileo> Like, does TegrabootCPU do some weird pass over a completely unused DTB?

09:56 <cyndis> u-boot does load the training data and patch the specified dtb with it, but I'm not sure of the exact mechanism (there are actually several..)

09:56 <oldgalileo> Ahhhhh cool. Okay, so the training data is passed down from TegrabootCPU through the boot chain into U-Boot rather than updating the DTB directly?

09:57 <cyndis> yeah, it might be passed as an in-memory DTB that u-boot then copies data from, though

09:58 <oldgalileo> cyndnis: Here's the thing that's fucking me up: there's a kernel_xxx.dtb file in the rootfs. Where is that getting written?

09:58 <cyndis> well, there might be systems where that in-memory DTB is used directly. there have been many revisions of this so it depends on chip and bootchain version

09:58 <oldgalileo> *from

09:58 <oldgalileo> Sure.

09:58 <cyndis> the flash script places it there

09:58 <cyndis> or something in the flash flow anyway

09:59 <oldgalileo> Okay, so that file should have no bearing on the actual boot process then, right?

09:59 <oldgalileo> Like, it should be loading the DTB from the DXB partition regardless of `/boot/dtb/kernel_xxx.dtb`

10:00 <cyndis> if it's not referenced in the extlinux.conf then I don't think so. on many systems extlinux.conf does reference it by default but I guess not on nano then

10:00 <oldgalileo> Yeah, cool. I think this was actually changed in an L4T release in late 2019.

10:05 <cyndis> yeah, having the kernel dtb be separate from the "bootloader dtb" is very useful from running upstream kernels so things have been moving in this direction

10:05 <cyndis> s/from/when/

10:29 <oldgalileo> Okay crazy. So are there reserved spots in the DTB that the TegrabootCPU goes and updates?

10:30 <oldgalileo> I'm binwalking through the partition DTB vs. the FS DTB to try to figure out wtf Tegraboot did.

10:34 <oldgalileo> Maybe this is actually done by the flashing script though.