On Mon, 2026-02-16 at 11:32 -0600, Andrew Davis wrote: > On 2/14/26 10:29 AM, Denys Dmytriyenko wrote: > > On Thu, Feb 12, 2026 at 04:03:34PM -0600, Andrew Davis via > > lists.yoctoproject.org wrote: > > > On 2/12/26 5:42 AM, Vitor Soares wrote: > > > > On Wed, 2026-02-11 at 18:52 -0600, Andrew Davis wrote: > > > > > On 2/11/26 11:15 AM, Vitor Soares via lists.yoctoproject.org wrote: > > > > > > Hi, > > > > > > While working on our Toradex Aquila AM69 SoM support, we noticed > > > > > > that k3.inc > > > > > > defines: > > > > > > SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS2" > > > > > > > > > > > > This caused systemd to enable [email protected] on our > > > > > > board, where > > > > > > ttyS0 maps to main_uart4 - a user-facing UART, not a debug/console > > > > > > UART. The > > > > > > getty continuously outputs a login prompt, interfering with the > > > > > > interface. > > > > > > > > > > > > This made us question whether SERIAL_CONSOLES belongs in SoC-level > > > > > > include > > > > > > files > > > > > > at all. Our understanding is that the console getty is already > > > > > > handled > > > > > > automatically by systemd-getty-generator from the console= kernel > > > > > > command > > > > > > line argument, which makes SERIAL_CONSOLES potentially redundant for > > > > > > the > > > > > > console > > > > > > UART. Any additional UARTs beyond the console are board-specific and > > > > > > arguably > > > > > > belong in each machine config rather than a shared SoC include. > > > > > > > > > > > > We are not 100% certain about this reasoning and would love to hear > > > > > > the > > > > > > rationale behind the current approach. Are we missing something? > > > > > > Would it > > > > > > make > > > > > > sense to either remove SERIAL_CONSOLES from the SoC includes or at > > > > > > minimum > > > > > > use > > > > > > a weak assignment (?=) to allow boards to override cleanly? > > > > > > > > > > We simply noticed almost all our EVM boards used the same console > > > > > UARTs and so > > > > > refactored the definition into a more common place. But yes you are > > > > > correct > > > > > that a file like k3.inc seems like it should contain only items common > > > > > to all > > > > > users of the K3 SoC family, and not simply common to TI EVM boards. > > > > > Changing > > > > > the assignment in k3.inc to a weak one seem reasonable (although I > > > > > think you > > > > > can still just override regular assignments after you include k3.conf > > > > > in > > > > > your board conf) > > > > > > > > > > > > > > > > > You're right we can override it in our board configs, but I wanted to > > > > share why > > > > we think this is worth reconsidering. > > > > > > > > The issue is that SERIAL_CONSOLES in k3.inc mixes SoC capabilities with > > > > board- > > > > specific UART usage. > > > > > > > > The K3 SoC provides the UART peripherals, but doesn't determine which > > > > ones are > > > > used for console, user interfaces, or other purposes - that's decided at > > > > the > > > > board level. > > > > > > > > Different boards use UARTs differently. On TI EVMs, ttyS2 or ttyS0 might > > > > be the > > > > debug console. On our Aquila AM69, ttyS2 is the console but ttyS0 is a > > > > user- > > > > facing UART. Same SoC, different UART assignments. > > > > > > > > SERIAL_CONSOLES creates getty login prompts on listed UARTs, which is a > > > > board/system integration concern. > > > > > > > > > > I think the same could be said about `IMAGE_FSTYPES` which is also in > > > `k3.inc` > > > but really should depend on the type of media on a board. > > > > > > > If TI's EVM boards share the same UART configuration, would it make > > > > sense to > > > > have a ti-evm-common.inc instead of putting it in the SoC include? > > > > > > > > Happy to help with refactoring if you think this direction makes sense. > > > > > > > > > > This directions makes sense to me, I'd have no issue with a ti-evm- > > > common.inc. > > > > This seems like an overkill for a single variable that can be easily > > resolved > > with a weak assignment. Moreover, this can quickly get out of hand with SKs > > and Beagles and how those sometimes have convoluted mixed ownership... > > > > > > > Or even since it is just 1 or 2 lines that would need to be moved out, > > > might > > > be easier to just move those lines back out to the different board > > > configs. > > > If you want to send the patch then up to you. > > > > Isn't it how it used to be originally? > > Yes, I'm basically saying I'm okay with reverting my patch[0] that > consolidated > these[0]. > > > > > The idea of a generic setting getting weakly assigned with a sane default > > is specifically to make it easy for downstream layers to change, while keep > > things maintainable upstream. > > > > We've been slowly trying to unify, cleanup and consolidate such settings in > > the past. To that extent, I keep reminding Ryan and others to avoid using > > :append override, which is hard to undo downstream, as well as use weak += > > instead of = for assigning SoC and machine settings. > > > > The patch that moved these to k3.inc used =, it should have used +=, so > changing that to += is also an option if we don't want to revert [0]. > > Andrew > > [0] > https://git.yoctoproject.org/meta-ti/commit/?id=bc894bf52eaa4359eaa64a64e950accd099a81cb > > > We've seen instances where a sane generic default works for most of the > > cases, > > but for a couple of cases need to be changed in more specific location. > > That's > > why we have hierarchical include structure from most generic to most > > specific: > > > > ti-soc.inc -> k3.inc -> j784s4.inc -> j784s4-evm.conf > > > > On the other hand, specifying U-boot defconfig (UBOOT_MACHINE/UBOOT_CONFIG) > > is > > almost always done in corresponding specific machine configs, simply becasue > > there's no generic default... > > >
Thanks for looking into this. >From an integrator perspective, I wanted to share the challenge we faced: when getty appeared on our user-facing UART, it wasn't immediately obvious this came from an inherited k3.inc default rather than our board configuration. We spent time investigating our device tree, systemd configs, and bootargs before discovering it was set at the SoC level. With systemd handling console getty automatically from console=, SERIAL_CONSOLES is mainly useful for additional serial ports with a login prompt, which are inherently board-specific decisions. Just wanted to share our experience as you consider the best approach. Thanks, Vitor
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19520): https://lists.yoctoproject.org/g/meta-ti/message/19520 Mute This Topic: https://lists.yoctoproject.org/mt/117760181/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
