Discussion:
Board detect on sunxi platform?
(too old to reply)
Stefan Mavrodiev
2017-07-07 12:48:01 UTC
Permalink
Raw Message
Hello,

I want to do automatic board detection for some SUN7I boards. What I've
done so far is:

- 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:
- Default target
- 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:
static int get_vbus_gpio(int index)
{
switch (index) {
case 0: return sunxi_name_to_gpio(CONFIG_USB0_VBUS_PIN);
case 1: return sunxi_name_to_gpio(CONFIG_USB1_VBUS_PIN);
case 2: return sunxi_name_to_gpio(CONFIG_USB2_VBUS_PIN);
case 3: return sunxi_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 linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andre Przywara
2017-07-07 16:23:41 UTC
Permalink
Raw Message
Hi,
Post by Stefan Mavrodiev
Hello,
I want to do automatic board detection for some SUN7I boards. What I've
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.
Post by Stefan Mavrodiev
* 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
|
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
|
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
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 linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...