Teltonika RUTX: dealing with uboot-selected multiple device trees

Hi, I'm currently thinking on adding support for a few additional devices of the Teltonika RUTX series, it seems to be that Teltonika switched from stm32-based gpio expander to 74HC595 shift registers(like they did with the RUT955), the only difference in the dts are leds and the gpio-controller.
As far as I can see TLT's firmware solves that by adding both* DTBs to the image and uboot selects it depending on the io_expander.

I did not find a way to find out which type of device one has without opening it or checking via ssh (in contrast to the RUT955 which has version/type hashes on the label).
Is there a clean way to do this in a similar way, so that we don't need to duplicate every RUTX device and let the users guess which firmware file they need?

[*] they actually add all DTB to a single firmware file, but I think that's definitely a bad idea.

1 Like

I see that the bcm27xx already builds images with multiple DTS:

define Device/rpi
  DEVICE_MODEL := B/B+/CM/Zero/ZeroW
  DEVICE_DTS := \
	bcm2708-rpi-b bcm2708-rpi-b-rev1 bcm2708-rpi-b-plus \
	bcm2708-rpi-cm \
	bcm2708-rpi-zero bcm2708-rpi-zero-w

for ipq40xx that would need a change to allow Device/FitImage /scripts/mkits.sh to appending multiple DTS, and then the device definitions would look somthing like:

define Device/teltonika_rutx14
	$(call Device/FitImage)
	$(call Device/UbiFit)
	DEVICE_VENDOR := Teltonika
	DEVICE_MODEL := RUTX14
	SOC := qcom-ipq4018
	DEVICE_DTS := 
		qcom-ipq4018-rutx14-stm32 qcom-ipq4018-rutx14-shiftreg
	(...)
endef

would that be something that would be accepted as a patchset to main?

That's best case scenario, You get single image for all devices.

Definitely. If U-Boot handles all devices with same SoC it would be even better, that way single image would cover all Teltonika devices in ipq40xx target.

in their SDK there's the full uboot code, i found exactly how a dts is selected at boot time.
basically the function conf_mdtb_select() looks for the uboot env variable "mnf_name", which is the two numbers of the current model (i.e. RUTX11 -> 11) if not falls back to "08", then finds out if it's an STM32 version by querying the chip through i2c, if so it appends "_STM32" to the "mnf_variable" content.

so, for example, a RUTX14 STM32 would produce "14_STM32".

then it queries the first 100 conf_mdtb@ entries of the fit config, looks at the description field, and compares it to the previously generated model version; if it matches, jump to bootm -> profit

i hacked together a modified version of the mkits.sh script from the sdk, as there's some differences in dts names and it booted on my RUTX14 STM32; will propose the addition in the RUTX11 pr (or try and build mine soon)