07:13 <walter> Hello, I have a noob question, how does one enable a serial console login on UART2? I have the kernel logs there, but I don't have a way to login. -- I'm trying this on an RK3399 with a new Yocto build of LTS Linux, not mainline, nor the Rockchips forked repositories. (thanks)

07:42 <qschulz> walter: provided your DTS enables UART2 with the proper mux, use SERIAL_CONSOLES in Yocto to set it up

07:42 <qschulz> walter: c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-SERIAL_CONSOLES

07:47 <walter> Thanks, didn't know about SERIAL_CONSOLES. I've only known about the DTS bootargs and stdout-path.

07:53 <qschulz> SERIAL_CONSOLES is only used for userspace applications IIRC, so this is unrelated to the kernel console

17:32 <pooyam> Hi! Why is there a difference in extent of kernel support for differnt brands of SBCs built around RK3588? Don't they just differ in things like amount of RAM, or input power tolerance and the like? https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md#rk3588-mainline-kernel-support

17:35 <CounterPillow> pooyam: the non-enumerable hardware on the boards, like things connected to SPI and I2C and other such, are described in device trees. These are board specific.

17:36 <CounterPillow> e.g. the kernel by itself does not know which USB controllers of the SoC are okay to enable and what kind of connector they're attached to, that's what the device tree tells it.

17:38 <CounterPillow> device trees aren't really specific to the Linux kernel though, they just happen to live in the Linux kernel repo and follow its release cycle. But for example u-boot uses them as well. In the hypothetical scenario where you have a u-boot platform firmware that does have a device tree, it can still EFI boot a generic UEFI OS image by passing it its device tree even if that OS image lacks that particular tree.

17:40 <pooyam> CounterPillow, Then how is this handled in general laptops? There are many brands of CPUs motherboards and peripherals.

17:41 <CounterPillow> pooyam: they also get their non-enumerable hardware described to them by the platform firmware. There it's usually some UEFI firmware with ACPI as the method to describe it, rather than DT.

17:42 <CounterPillow> the difference is that when you buy a laptop there's already platform firmware on it, but when you buy an SBC you are likely to either have nothing on it or some downstream vendor stuff that does not comply with upstream DT bindings or even has a new enough firmware to do EFI boot

17:48 <pooyam> CounterPillow, if a SBC A and B were designed that each provide such platform firmware, then kernel support for them would not be different, right?

17:51 <CounterPillow> correct, but SBC manufacturers usually just want to support whatever rockchip BSP kernel they use, which will use DT bindings that aren't compatible with upstream bindings. Switching out DT for ACPI doesn't really help here either because then you're just making up new ACPI interfaces that no OS kernel supports to describe your devices. The various edk2 forks had to learn this the hard way.

17:53 <pooyam> CounterPillow, thanks. A general question, I wonder, is it the case that RockChip has a closed-source linux support for their boards for testing but doesn't release it? If they haven't tested their hardware with proper firmware, how could they be sure that various hw submodules work correctly with each other according to spec?

17:53 <CounterPillow> it's open source, it's the BSP kernel

17:53 <CounterPillow> it's a device-specific fork of the Linux kernel, which is the standard practice for Arm hardware vendors

17:54 <pooyam> and using that fork, every feature works even NPU?

17:54 <CounterPillow> sure, but using wildly different userspace interfaces.

17:55 <pooyam> This fork is the same thing OEM "Android" images are using in things like retro gaming SBCs?

17:55 <CounterPillow> yes

17:56 <pooyam> > widely different user-space: as in outdated versions since they used an older branch of kernel?

17:57 <pooyam> In other words, the Ubuntu they provide, has support for every feature, but the apps on it are outdated and can't be upgraded

17:57 <CounterPillow> that too, but they also create vendor-specific APIs for userspace to call into the kernel with, instead of finding solutions that work for more than one vendor and lessens the burden on application developers.

17:59 <pooyam> if vender-specific APIs is problematic, Andorid apps should have problems too, no? But we often see OEM images are more performant and stable on the OEM image

18:00 <pooyam> s/OEM images/apps

18:01 <CounterPillow> That's why most of these never update their Android version ;)

18:02 <pooyam> CounterPillow, what's in it for RockChip to be in sync with main branch of kernel?

18:02 <CounterPillow> what do you mean?

18:02 <pooyam> If they sell their custom Android to buyers and buyers (big OEM) are ok with this?

18:03 <pooyam> What's the financial incentive for rockchip to support mainline?

18:04 <CounterPillow> They don't have to spend engineering hours rebasing their old patches onto a much newer kernel version whenever they want to support a SoC with a newer BSP version.

18:05 <pooyam> Other companies are worse than RC in this regard, do you agree? For example snapdragon I think is worse

18:05 <CounterPillow> Though it's not like they invest a huge amount of time, a lot of the work is being done by consultancies like Collabora and by volunteers, because there is a minority of companies and people who do not want to run vendor BSP kernels. But the vast majority of e.g. Android phone companies are okay and even expect to run vendor kernels, that's why they don't ship updates anymore after 2 years.

18:06 <pooyam> yes

18:06 <CounterPillow> It's hard to compare in absolute numbers. Qualcomm has a lot more chips but they do actually pay people to add support in mainline Linux for them now, there's just a lot of work to be done

18:08 <pooyam> pricewise, does RK3588 have a competetor that is more friendly regarding mainline support? Intel N100?

18:09 <pooyam> And I guess the support for RK3668 has not started yet...

18:12 <CounterPillow> I don't have a complete overview of the SoC landscape, but yeah Intel N100 fits the bill I guess. RK3668 isn't released yet and I'm not sure if it has even had engineering samples taped out yet, so it'll be a while before people will work on mainline support for it

18:17 <CounterPillow> Another company that's making some headway in mainline support is MediaTek. Radxa for example sells the NIO 12L, which we coincidentally also have a mainline status matrix for. https://gitlab.collabora.com/mediatek/aiot/wiki/-/blob/main/mainline-status.md?ref_type=heads

18:31 <pooyam> CounterPillow, thanks

18:35 <Ermine> What about Unisoc btw?

18:36 <CounterPillow> practically no mainline kernel support and they don't seem to contribute much either

18:39 <Ermine> ugh, I see.

18:41 <Ermine> btw is Collabora contracted for kernel mainlining?

18:42 <Ermine> mainlining Rockchip stuff that is

18:42 <CounterPillow> I can't talk about specifics of the business side I don't think

18:46 <Ermine> ok, sorry

18:47 <CounterPillow> not a faux-pas to ask, just not my question to answer ;)