Hi,
On 07/07/17 13:48, Stefan Mavrodiev wrote:
> Hello,
>
> I want to do automatic board detection for some SUN7I boards. What I've
> done so far is:
Partly your problems are addressed by device trees, which describe the
exact routing of pins on a particular board, for instance.
Unfortunately sunxi is not using DTs for many core peripherals (clocks,
pinctrl, mmc), hence the hardcoding you complained about below, but
there is(?) ongoing effort to fix this. This should then address the
issues you mentioned below.
But: actual automatic *board* detection is quite hard to do safely. If
you can restrict yourself to a (limited) subset of boards, you could use
some heuristics (like: amount of DRAM, has an eMMC on MMC2, has some
PMIC with some specific ID connected to I2C1), but this is quite error
prone and you will soon find two indistinguishable boards.
A very simple version of that is used for the Pine64, where we derive
the board model from the DRAM size and deduce a Pine64 when we have less
than one GB of DRAM, and a Pine64+ otherwise.
Check board_fit_config_name_match() in board/sunxi/board.c.
This is using FIT loading in the SPL, where we include multiple DTs and
select the proper one by the the return value of this function.
A more safer version is also implemented there: the board is identified
by the device tree file name (stub) in the SPL header and the DT is
selected accordingly. So you can have one firmware image with multiple
DTs, supporting multiple boards, but you would need to eventually write
the right board name to the beginning of that firmware image file.
Or do you mean multiple SoC support? This can be checked by some SoC ID
values (we do this in sunxi-tools already), but still can't distinguish
boards as mentioned above.
Cheers,
Andre.
> * Make my own board/<vendor>/<name>
> * In the Makefile request dependencies from board/sunxi directory, e.g.
>
> |
> obj-$(CONFIG_SUNXI_GMAC)+= ../../sunxi/gmac.o
> |
>
> |
> obj-$(CONFIG_SUNXI_AHCI)+= ../../sunxi/ahci.o
> |
>
> |
> obj-$(CONFIG_MACH_SUN7I)+= ../../sunxi/dram_sun5i_auto.o
> |
>
> * In arch/arm/mach-sunxi/Kconfig I've added menu:
> o Default target
> o My own target
>
> Based of the choice I change SYS_BOARD, SYS_VENDOR, SYS_CONFIG_NAME
> to point to my directory
>
> * In my board.c file is pretty much the same as board/sunxi/board.c
> without lot of switches, etc. Also I make some board detection and
> set some u-boot variables.
>
>
> So far so good.
> The problem is driver initialization. Fox example in
> arch/arm/mach-sunxi/usb_phy.c there is this code:
> |
> staticintget_vbus_gpio(intindex)
> {
> switch(index){
> case0:returnsunxi_name_to_gpio(CONFIG_USB0_VBUS_PIN);
> case1:returnsunxi_name_to_gpio(CONFIG_USB1_VBUS_PIN);
> case2:returnsunxi_name_to_gpio(CONFIG_USB2_VBUS_PIN);
> case3:returnsunxi_name_to_gpio(CONFIG_USB3_VBUS_PIN);
> }
> return-EINVAL;
> }
> |
>
> On board A I have VBUS_PIN on "PC0", on board B - "PC1", on board C -
> "PC2". How I'm supposed to do this, without doing some s**** things?
>
> Also, I'm the first trying to do such thing?
> In general, is this correct? Can it go mainline? If not, what you recommend?
>
> Best regards,
> Stefan Mavrodiev
>
> --
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
