关于重新编译cboot的问题

我这边现在遇到一点问题，对于使用ttyTHS1串口，当启动系统时，如果这个串口收到一串数据，就导致了卡在下面这种界面，下位机主动上报是我这边调整不了的，所以只能在系统层面想办法了

[0007.551] I> Validate extlinux.conf ...
[0007.554] I> T19x: Authenticate extlinux.conf (bin_type: 54), max size 0x2000
[0007.561] I> Encryption fuse is not ON
[0007.565] I> L4T boot options
[0007.567] I> [1]: "primary kernel"
[0007.571] I> Enter choice:
[0007.573] I> Invalid option: d
[0007.576] I> Enter choice:
[0007.602] I> Invalid option: d
[0007.602] I> Enter choice:
[0007.753] I> Invalid option: d
[0007.753] I> Enter choice:
[0007.920] I> Invalid option: d


       我搜了搜论坛，提了一个帖子，说需要重新编译cboot，在系统启动过程中不等待串口的任何输入，但是我不知道修改哪里，上面说让自己修改，想问问米文动力这边了解如何具体操作么；       同时我也想知道，按道理来讲不应该是调试口收到输入的时候才会对系统启动有影响么，通信串口按理来说不应该呀，这个ttyTHS1串口，官方的镜像也把启动信息输出到这个串口了，我已经修改了配置文件，把这个功能给禁用了

您好，感谢您的支持。
请问您是使用了我们的哪款设备，遇到的这个问题呢？
我们也希望能够了解一下您的具体场景，看是否能够帮助您解决这个问题。
但是cboot方面，原则上我们是不支持客户修改的（但会通过项目支持客户），因为一方面cboot不属于产品功能范畴，另一方面修改引申的问题我们也无法支持。
另外，据我了解，ttyTHS1节点应该不会引入设备进入cboot的，根据我们的测试，只有在启动过程中debug串口一直收到数据才会卡在cboot，您也可以依次插拔几个串口来检查到底是哪个串口出的问题。
谢谢

实话实说哈，不是您公司的设备，只不过之前从您公司购买过不到20套的8网口的NX，想咨询一下您这边的技术有没有懂我这边遇到的这个问题，底板是我们自己做的，场景就是一个下位机会定时主动上报一些数据，然后接在了ttyTHS1上，当系统启动过程中收到数据就卡在了cboot启动过程中（这块我不知道我说的是否准确），我理解debug串口收到数据进到别的模式里面是对的，通信串口不改这样 ，同时官方镜像也将系统启动信息默认输出到了ttyTHS1，我已经将这个服务禁了，有没有可能禁用的不彻底呢，或者禁用方式不对

不好意思，您说的这个问题我们之前没有遇到过。我们设备ttyTHS1串口不影响镜像的正常启动。
相关问题建议您可以直接反馈给英伟达，比如通过在英伟达论坛上直接发帖子的方式（https://forums.developer.nvidia.com/），他们的工程师可能会有一些特别的见解。

毒药 发表于 2022-5-18 17:04
不好意思，您说的这个问题我们之前没有遇到过。我们设备ttyTHS1串口不影响镜像的正常启动。
相关问题建议您 ...

嗯，已经在nvidia论坛上发过帖子了，上面建议重新编译cboot，但是没说修改哪里
同时我发现从您公司购买的nx，nvgetty这个服务是没有禁用的，之前都说这块需要禁用，因为官方镜像是把调试信息输出到了这个串口ttyTHS1，我不知道您这边是如何保证这个串口不被占用的，