On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote:
LiNova1 is not a board with various headers to connect other peripherals
such display, pcap etc.
It's an HMI that I would consider the same as a Tablet, because it has a
plastic enclosure also.
So I would like to understand how to manage it in the best way.
Try to consider LiNova1 as a Tablet series, with following list:
LiNova1 4.3" ctp
LiNova1 7" ctp
LiNova1 10.1" ctp
LiNova1 4.3" rtp
LiNova1 7" rtp
LiNova1 10.1" rtp
Every of those has a slightly different BOM, so they are 6 different
boards with a common base(uP, ram). And same pcb.
So the LiNova1 is exactly the same in all these setups, the only
difference is that it has a connector that you connect a different
display / touchscreen to?
If so, that's definitely a case for device tree overlays.
So I don't know if submit only the common base and provide
separately on our github DT-overlays, or provide as many dts patches
as the HMI number with a base dtsi.
That's really up to you, but the overlays will make this much simpler
to handle precisely because it will reduce the amount of combinations
You can even reduce it in your case to 5 of them, 3 for each panel and
2 for each touchscreen.
Basically Micronova provides entire system without the capability to hack
hardware adding shields of various type.
There are also other 2 LiNova:
LiNova2 and LiNova3
Which SoCs are these boards based on?
So I understand that this could lead to 18 different dts files and 3
Yeah, I'd really like to keep this under control :)
But with Tablet it should be the same way. For sure people would be
more interested on famous tablets instead of our HMI.
In the case I need to use dt-overlays, you mean .dto files with
fragments inside loaded by u-boot or runtime, right?
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
+ dr_mode = "otg";
You're saying that this is a USB-A connector? Then it's not OTG since
it doesn't have an ID pin, this is an host.
Right, with a special overlay I will activate Usb Device for RNDIS,
so modified as host
That doesn't really make much sense. The USB OTG is wired only using a
My fault, I've meant "peripheral" in one case and "host" in another case.
Are there problem with this?
There is no daughter board.
If you have an ID pin and the ability to control VBUS, then you don't
need to change the device tree, it's done automatically at runtime by