At this point I know it is CSI, so that’s what I’m looking at. CSI is not hotplug, and so device tree matters. There is likely a GPIO being set up for i2c communications which is part of the CSI, but sort of “separate” in configuration.
It is correct that cables can have an extreme effect on high speed data lines. CSI qualifies as this, and as resolution goes up, the speed has to go up if the frame rate is to remain the same. So high res quality issues can (and in fact might be in your case) be the cause of lower quality. Cables can go as far as causing complete failure even if they are ok with DC electricity (AC, especially as the frequency goes high, has issues with reflections; this is more of a problem with square waves used in digital lines). You’d need to start a different thread on CSI cables (I know RF engineering, but CSI and cameras are not my field).
A serial console boot log cares about “quiet” being removed, whereas flash logs won’t be affected by this.
Just commenting on things as I go through the ZED flash log…
I see some notes of PMIC rail info not being found. This is the power management IC. There are different rails for different parts of the system, including i2c rails and rails which might affect cameras over CSI. This could cause a failure of a component simply because a device tree is not locating the item (or the rail that powers the item). Sometimes there are more rails being tested in flash than might actually exist on a model, so it might not always be an error. In addition to this, I see the information about being missing is in the MB1 BCT (master boot 1 is very early boot; BCT is the boot control table), but then it says “DONE”. Example log lines:
[0000.911] W> PMIC_CONFIG: Rail: GPU rail info not found in MB1 BCT.
[0000.917] I> DONE: GPU rail info
[0000.921] W> PMIC_CONFIG: Rail: CV rail info not found in MB1 BCT.
[0000.927] I> DONE: CV rail info
Perhaps config worked from some future step? Don’t know, but in part we are in the realm of what a device tree might solve…finding rails or parts of the system which are general purpose and might move (physical address might move).
Further down here are some similar items, but they were successes ():
0001.248] I> Binary name: BPMP_FW_DTB
[0001.252] I> Size of crypto header is 8192
[0001.256] I> Size of crypto header is 8192
[0001.260] I> strt_pg_num(13056) num_of_pgs(16) read_buf(0x807fc0000001.248] I> Binary name: BPMP_FW_DTB
[0001.252] I> Size of crypto header is 8192
[0001.256] I> Size of crypto header is 8192
[0001.260] I> strt_pg_num(13056) num_of_pgs(16) read_buf(0x807fc000)
[0001.266] I> BCH of BPMP_FW_DTB read from storage
[0001.270] I> BCH address is : 0x807fc000
[0001.274] I> BPMP_FW_DTB header integrity check is success)
[0001.266] I> BCH of BPMP_FW_DTB read from storage
[0001.270] I> BCH address is : 0x807fc000
[0001.274] I> BPMP_FW_DTB header integrity check is success
[0001.280] I> Binary magic in BCH component 0 is BPMD
If you look closely at this, this is a case of a device tree fragment for the BPMP (boot power management processor) which is being read from a partition as binary data. This was added to a partition via flash, and is an alternate location for such content. Assuming security fuses were not burned, a device tree which is accessible in /boot, and configured to be used with extlinux.conf, would take priority over this. Normally (without security fuses burned) this would only be read from the partition if (A) extlinux.conf did not say to use a device tree in a file of /boot, or if (B) the file named is not found. If the boot stage is too early to access extlinux.conf, then content might be read there anyway (this qualifies as extlinux.conf not specifying a device tree). Perhaps what is in the partition is correct only for NVIDIA dev kits, but perhaps only tiny parts of this are wrong on your Seeed carrier board. The parts (fragments) which are correct would work.
Now I’m looking for signs of a device tree file being loaded, rather than a partition being loaded. In particular it would be useful to see what it says is loaded for the Linux kernel rather than from early boot stages, or anything that might be related to the camera or CSI.
I see:
[ 5.819549] Camera-FW on t234-rce-safe ready SHA1=e2238c99 (crt 0.891 ms, total boot 48.238 ms)
This might just be an early stage setup and might not matter, but if it does matter, then this is a big deal:
E/LD: init_elf:486 sys_open_ta_bin(bc50d971-d4c9-42c4-82cb-343fb7f37896)
E/TC:?? 00 ldelf_init_with_ldelf:131 ldelf failed with res: 0xffff000c
I don’t know enough about this software to say if this matters, and there is more than one way to start the linker, but at this early part of boot a lack of ELF libraries being able to load (ld is the linker) only statically linked programs would succeed. Everything depending on a library would fail. The log is not done yet though, so maybe further down there are clues of success. Incidentally, boot stages are always bare metal, and do not link; the Linux kernel itself is also bare metal and works without linking. This point in the logs is right at the start of changing from boot content to Linux kernel, and so probably this does not matter.
Sadly, these log lines would be more useful if it gave actual file names:
L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services...
I see no further mention of device tree (addresses mentioned for things like i2c would be from the earlier device tree, but that might be the one in the partition).
This might say that power management is set up wrong:
[ 9.121659] ACPI: <n/a>: failed to evaluate _DSM (0x1001)
The good news is that it does boot and allow login. I did not see anything particularly relevant to the camera.
The detail to remember while continuing on is that the device tree that is put into a partition during flash is the one which is used. On such a system we could add a file type .dtb in /boot, modify extlinux.conf, and test without flashing again. Once we see the same thing on the Seeed flash and boot log we will know about what device tree is used there. Then we can try to find the device tree used by ZED for the partition, and compare. If there is a difference related to CSI, then that can be edited, and then the Seeed version might work (you’d want to save a safe copy of that edited tree, or at least the fragment of the tree being edited).
Even so, I did not see a lot of failures on the ZED version. Is the only reason you use a particular release (Seeed versus ZED) due to the high resolution settings having a low image quality?
