Hi team ,
We have created sucessfully the default BSP for the NVIDIA T30 and tested the same after flashing the same on SD card , board boots fine and we get the console properly
Below are the two queries which we would seek inputs from the team as i could not figure any thing in documentation :-
a) Why there is no tegra30-apalis-eval.dtb being present in the default created setup ( I tested the same with Apalis-T30_LXDE-Image_2.7b2-20170410.tar.bz2 availanble from Toradex binary repositary )
We came to T30 after using iMX6 .
Does T30 doesn’t support DTB or the binary are wrongly created ?
Attached is the snapshot of problem 
- Which branch of git are we supposed to use (tegra or tegra-next ) to download
the linux kernel for NVIDIA T30 SOC from linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
Thanks
a) Why there is no tegra30-apalis-eval.dtb being present in the default created setup (I tested the same with Apalis-T30_LXDE-Image_2.7b2-20170410.tar.bz2 available from Toradex binary repository).
Our regular BSP is based on NVIDIA’s latest L4T R16.5 whose Linux kernel 3.1.10 does not yet support device trees.
We came to T30 after using iMX6. Does T30 not support DTB or the binary is wrongly created?
It does support DTB just fine e.g. when using a mainline Linux kernel.
- Which branch of git are we supposed to use (tegra or tegra-next ) to download the Linux kernel for NVIDIA T30 SOC from linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
Usually that would be the tegra branch off which we release our official BSPs unless you specifically want to test some upcoming features not yet completely tested only available on the tegra-next branch.
Thanks Marcel for pointers …
Could you please provide anyt documentation where in i could understand the spidevice to spicontroller binding .
This is required because we need to alter some parameters of SPI controller & build our own custom spi client driver.
(In iMX6 i did this modifying dts file and binding our cuistom driver)
I’m actually just in the process of updating our developer website article and you may get a glimpse on a pre-release here. Does that answer your question? If not please be a little bit more specific as to what exact information you are looking for.
Not sure if the below mentioned inputs can be added in the above mentioned doc , but to give you an top idea of our requirement :-
a) Bind the custom ADC7606 driver ( the probe of this ) @ SPI-0 should be called after init ( This will happen if there is proper binding with the default spi controller )
b) Pinmux some pins & allocate an GPIO to this device.
c) My last implementation was something like below mentioned ( in device tree ) :-
adcc7606-8@0 {
compatible = "adi,adcdata7606-8";
reg = <0>;
spi-max-frequency = <18000000>;
/* PINMUX to get the GPIO02 */
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_adcc7606>;
gpio_pin_number = <&gpio1 2 0>;
};
Hence way to properly do driver binding + pinmux + gpio pin allocation is what i am looking
(would be helpful if you share some pointers / documentation available as i would be doing this activity for the first time )
Not sure if the below mentioned inputs can be added in the above mentioned doc, but to give you an top idea of our requirement :-
Yeah, seems just slightly out-of-scope (;-p).
a) Bind the custom ADC7606 driver ( the probe of this ) @ SPI-0 should be called after init ( This will happen if there is proper binding with the default spi controller )
Such would need to be done via board file aka platform data as e.g. in the MCP2515 SPI CAN controllers case here.
b) Pinmux some pins & allocate an GPIO to this device.
No special pin muxing is usually required for Tegra 2/3 devices as requesting a GPIO automatically takes care of it (unless of course it would have been tri-stated or its input driver disabled). Therefore GPIOs can just be requested/used as e.g. in the touch interrupt case here.
c) My last implementation was something like below mentioned ( in device tree ) :-
As mentioned before one could of course also use a mainline Linux kernel with exactly the same device tree concepts. However the exact feature set would have to be assessed.
Hence way to properly do driver binding + pinmux + gpio pin allocation is what i am looking (would be helpful if you share some pointers / documentation available as i would be doing this activity for the first time )
Understood. Unfortunately for the older Tegra 2/3 BSPs there is not much generic such documentation available.
