Hi @JerryChang
use previous backuped u-boot.bin to replace Linux_for_Tegra/bootloader/t186ref/p2771-0000/500/u-boot.bin, and ./flash.sh -r -k kernel jetson-tx2 mmcblk0p1 again.
serious console log shows that “U-Boot 2020.04-g46e4604c78 (Jul 26 2021 - 12:10:58 -0700)”, which is difference from Topic218834_u-boot.bin (U-Boot 2020.04-g1290f21 (Jun 17 2021 - 15:56:34 +0800))
is it timestamp?
So confused that why we have replaced back u-boot.bin successfully, but during boot-up it still ask user to select boot options. We expect device load tegra186-quill-p3310-1000-c03-00-base.dts, and bringup.
Regards
hello Henry.Lou,
it’s /boot/extlinux to define boot options, however, I’m a little confused why primary kernel cause system halt. do you have customize board?
Hi @JerryChang
At first, we port tlv sound card to the TX2 develop kit, and we found that expanded 40-pin header cannot be configed. The aud_mclk can not send clock signal out. So, we post our question on forum on 26 Jun.
But, on 27 Jun, we got customize board, so since then, all operations were based on it.
Such as, record serious console logs, modify /boot/extlinux, flash u-boot.bin, etc.
But, now the situation seems get worse.We expect go back to Jun 27 status, so we flashed system.img by the command “./flash.sh -r jestson-tx2 mmcblk0p1” successfully. But, system call trace and reboot again.
And, we transfer back to TX2 develop kit, same situation.
Attachment is serious console log.
FYI
2022-06-29_14_32_53.log (49.4 KB)
quick question, are you able moving to JetPack-4.6.1 for development?
Hi @JerryChang
The project contains some developed features such as ported cameras, so it is time-consuming to change SDK platform. Now, we expect to recover to status of 27 Jun, and then modify tegra186-quill-p3310-1000-c03-00-base.dts directly. So that our work can go on.
hello Henry.Lou,
am I understand correctly that you have this command to flash your customize board?
if yes, then it’s expect to have such failure since this will use the TX2 DevKit’s configuration file.
please refer to Jetson TX2 Series Adaptation and Bring-Up, you must change the pinmux configuration applied by the software. or, please assign correct cfg file and flashing your target.
Hi @JerryChang
if pinmux configuration lead to kernel panic, why the device worked well on 27 Jun, noting that firmware was not changed.
and the attachmant is latest log, could you help to locate trouble?
2022-06-29_15_30_44.log (151.7 KB)
hello Henry.Lou,
it should be full flash, ./flash.sh -r jestson-tx2 mmcblk0p1 to cause the failure.
according to below, there’s call trace from device tree,
[ 6.542213] Hardware name: quill (DT)
[ 6.546901] Call trace:
[ 6.550368] [<ffffff800820ba40>] dump_backtrace+0x0/0x198
[ 6.556789] [<ffffff800820c004>] show_stack+0x24/0x30
[ 6.562874] [<ffffff80090a5a1c>] dump_stack+0xa0/0xc4
[ 6.568973] [<ffffff80090a2ac0>] panic+0x12c/0x2a8
[ 6.574804] [<ffffff80090a84d4>] kernel_init+0xf4/0x108
[ 6.581028] [<ffffff80082038a0>] ret_from_fork+0x10/0x30
and… this is the device tree blob build by yourself on Jun 29.
[ 0.184629] DTS File Name: arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts
[ 0.184643] DTB Build time: Jun 29 2022 15:21:12
would you please review the modifications, and please check you’ve update $OUT/Linux_for_Tegra/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb for flashing the target.
Hi @JerryChang
We reverted DTS, rebuilt dts, fashed kernel-dtb. But, got same response.
What`s more, we tried replace tegra186-quill-p3310-1000-c03-00-base.dtb with the original one, but got same response.
It is so serious that our work has been halted.
hello Henry.Lou,
did you mean even the TX2 DevKit cannot boot-up even you’ve revert all changes back to default JetPack release image?
it’s suggest to fully remove installation folder and re-create the system.img for confirmation.
Hi @JerryChang
not revert all changes, ontly revert DT back to JetPack release image.
Yes, we have backuped the JetPack released tegra186-quill-p3310-1000-c03-00-base.dtb, we cp it to platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts, flashed kernel-dtb on the DevKit.
We are gonna have a try remove installation folder and re-build system.img. And if faila again, we will try download SDKmanager, and flash released image on the DevKit.
bless us
Hi @JerryChang
Good news, we rebuilt system.img and reflashed to Developer Kit, our device bring up successfully.
But, a new problem faced us.
As used to do, we modified nvidia/platform/t18x/common/kernel-dts/t18-common-platforms/tegrar186-quill-common.dtsi,
after that, cd kernel/kernel-4.9, and “make dtbs”.
cp “sources/kernel/kernel-4.9/arch/arm64/boot/dts/tegra186-quill-p3310-1000-c03-00-base.dtb” to “kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb”.
Finally, run “./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1”.
But, if we choose [Custom Header Config] of L4T boot options, the modification of DT will never be loaded (refer to 2022-06-30_17_21_53.log). if we choose [primary kernel], the modification will work well (refer to 2022-06-30_17_20_10.log ).
And, in both cases, our device can bring up.
So, could you help us to make modified DT work？Is the above procedure right? If not, could give us SOP to modify and flash our DTS?
Regards
FYI
2022-06-30_17_21_53.log (49.9 KB)
2022-06-30_17_20_10.log (54.7 KB)
hello Henry.Lou,
there’re two ways to load the device tree blob. 1) read from kernel-dtb partition, 2) read from file system via FDT entry.
however, if you’ve specify FDT entry in the extlinux.conf file, cboot prior to load the kernel-dtb binary file from FDT entry.
Hi @JerryChang
We are confused that, the [Custom Header Config] FDT only overlay 40-pin header, it does not matter with the tlv320@18 node. our procedure in the previous comment#32 modified tlv320@18 node, reflashed base dtb to kernel-dtb partition. Why cannot the base of DT work?
We thought that the base dtb file is like a foundation, other FDTs are based on it, and the dtbo file only over-write the properties of nods which are listed in the “_overlay_” node.
Could help us to config audio_mclk and i2s1 manually, without the jetson-io.py. We mean that add node and properties to base dtbs.
Regards
hello Henry.Lou,
you may download pinmux spreadsheets to customize the board configurations, please see-also pinmux changes session to change the pinmux configuration applied by the software.
thanks
Hi @JerryChang
There are two .cfg files.
bootloader/t186ref/BCT/t186/pinmux/tegra186-mb1-bct-pinmux-quill-p3310-1000-c03.cfg
bootloader/tegra186-mb1-bct-pinmux-quill-p3310-1000-c03.cfg
which one should we modify? and use what command to fash .cfg to our device?
accoring to this topic, we modified .cfg file and use “./flash.sh -r -k kernel jetson-tx2 mmcblk0p1”. However, pinmux not changed.
hello Henry.Lou,
bootloader/tegra186-mb1-bct-pinmux-quill-p3310-1000-c03.cfg is the cfg file that flash to the target.
please perform full flash instead, a partition update (i.e. -k kernel) did not apply the cfg file.
Hi @JerryChang
according to this topic, we modified .cfg file.
device bring up and confirm regs:
Bank: 0 Reg: 0x02431020 Val: 0x00000400 -> aud_mclk_pj4
Bank: 0 Reg: 0x02431028 Val: 0x00000440 -> dap1_fs_pj3
Bank: 0 Reg: 0x02431030 Val: 0x00000458 -> dap1_din_pj2
Bank: 0 Reg: 0x02431038 Val: 0x00000400 -> dap1_dout_pj1
Bank: 0 Reg: 0x02431040 Val: 0x00000400 -> dap1_sclk_pj0
However, device bring up, The dmesg shows error “Failed getting the mclk. The current implementation does not support the usage of this codec without mclk”.
We traced to tlv320aic32x4.c file tlv320aic32x4.log , and found that devm_clk_get() function failed. Could you give us some advices?
int aic32x4_probe(struct device *dev, struct regmap *regmap)
{
struct aic32x4_priv *aic32x4;
struct aic32x4_pdata *pdata = dev->platform_data;
struct device_node *np = dev->of_node;
int ret;
if (IS_ERR(regmap))
return PTR_ERR(regmap);
aic32x4 = devm_kzalloc(dev, sizeof(struct aic32x4_priv),
GFP_KERNEL);
if (aic32x4 == NULL)
return -ENOMEM;
dev_set_drvdata(dev, aic32x4);
if (pdata) {
aic32x4->power_cfg = pdata->power_cfg;
aic32x4->swapdacs = pdata->swapdacs;
aic32x4->micpga_routing = pdata->micpga_routing;
aic32x4->rstn_gpio = pdata->rstn_gpio;
} else if (np) {
ret = aic32x4_parse_dt(aic32x4, np);
if (ret) {
dev_err(dev, "Failed to parse DT node\n");
return ret;
}
} else {
aic32x4->power_cfg = 0;
aic32x4->swapdacs = false;
aic32x4->micpga_routing = 0;
aic32x4->rstn_gpio = -1;
}
aic32x4->mclk = devm_clk_get(dev, "mclk");
if (IS_ERR(aic32x4->mclk)) {
dev_err(dev, "Failed getting the mclk. The current implementation does not support the usage of this codec without mclk\n");
return PTR_ERR(aic32x4->mclk);
}
if (gpio_is_valid(aic32x4->rstn_gpio)) {
ret = devm_gpio_request_one(dev, aic32x4->rstn_gpio,
GPIOF_OUT_INIT_LOW, "tlv320aic32x4 rstn");
if (ret != 0)
return ret;
}
ret = aic32x4_setup_regulators(dev, aic32x4);
if (ret) {
dev_err(dev, "Failed to setup regulators\n");
return ret;
}
ret = snd_soc_register_codec(dev,
&soc_codec_dev_aic32x4, &aic32x4_dai, 1);
if (ret) {
dev_err(dev, "Failed to register codec\n");
aic32x4_disable_regulators(aic32x4);
return ret;
}
return 0;
}
hello Henry.Lou,
aic32x4->mclk = devm_clk_get(dev, "mclk"); it a function call to get the parent clocks,
do you have a name of the input clock for the camera device, which should define in the device tree; there’s default input clock, mclk the value is extperiph1, its maximum frequency is 24-MHz.
for example,
you should also have below definition for your sensor driver.
i2c@3180000 {
i2c@0 {
aic3204@Address {
clock-names = "extperiph1", "pllp_grtba";
mclk = "extperiph1";
BTW,
I don’t see compatible definition in your sensor driver, which must match what is specified in sensor’s device tree node. the Linux kernel uses this member to identify and bind the driver to the sensor.
please check Individual Imaging Device session to review your driver.
Hi @JerryChang
yes, we added tlv sound card node to i2c bus 1. and more details can reffer to attachment i.e. tegra186-quill-common.dtsi.
i2c@c240000 {//regist the device to i2c-1 bus
// added by henry for tlv320
tlv320: tlv320@18 {
compatible = "ti,tlv320aic32x4";
reg = <0x18>;
clocks = <&tegra_car TEGRA186_CLK_AUD_MCLK>;
clock-names = "mclk";
henry = "henry_test";
status = "okay";
};
// added by henry
};
wrt compatible, there is other driver named tlv320aic32x4-i2c.c, which has compatible property, match sound card, and will call the probe function in the tlv320aic32x4.c file tlv320aic32x4.log
FYI
tegra186-quill-common.dtsi (33.9 KB)