[OpenWrt-Devel] [PATCH 2/2 v4] linux: add support of Synopsys ARC770-based boards

[Alexey Brodkin]

Hi Jonas,

On Wed, 2015-11-11 at 13:47 +0100, Jonas Gorski wrote:
> On Wed, Nov 11, 2015 at 1:38 PM, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> > Hi Jonas,
> > 
> > On Wed, 2015-11-11 at 12:19 +0100, Jonas Gorski wrote:
> > > Hi Alexey,
> > > 
> > > On Tue, Nov 10, 2015 at 5:40 PM, Alexey Brodkin
> > > <Alexey.Brodkin at synopsys.com> wrote:
> > > > Hi Jonas,
> > > > 
> > > > On Tue, 2015-11-10 at 12:02 +0100, Jonas Gorski wrote:
> > 
> > > > > Hi Alexey,
> > > I see what you want, but the way you are doing it is quite error prone
> > > and inefficient. If you insist on using the compatible, i suggest:
> > > 
> > > 1. Extract the first one instead of grepping through the full
> > > compatible set, so you don't need to invoke grep for each comparison
> > > (also dropping the misuse of cat ;p).
> > 
> > The problem is how multientry compatible string is presented in /proc fs:
> > -------------------->8------------------------
> > $ cat /proc/device-tree/compatible
> > snps,axs101snps,arc-sdp
> > -------------------->8------------------------
> > 
> > You see there's no delimiter between "snps,axs101" and "snps,arc-sdp".
> > So how should I extract "snps,arc-sdp" from /proc/device-tree/compatible?
> 
> Well, you want to use it, you figure it out ;p.
> 
> This is mostly a display issue. If you look at the actual data with
> e.g. hexdump:
> 
> 62 72 63 6d 2c 62 63 6d  39 36 33 32 38 61 76 6e  |brcm,bcm96328avn|
> 67 00 62 72 63 6d 2c 62  63 6d 36 33 32 38 00     |g.brcm,bcm6328.|
> 
> you will see that these are two properly null-terminated strings. It's
> just that printing to stdout swallows the terminators, but anything
> working with the data should properly see them as two distinct values.

Thanks for the hint. I do see now an example in
bcm53xx/base-files/lib/upgrade/platform.sh.

But again note that as of today we (ARC) have only one board (ARC SDP)
which has "compatible" string that consists from 2 sub-strings.

All other boards we have now in upstream have simple "compatible" sting.
What worse ARC SDP's "compatible" property mentions its flavor "axs101" or
"axs103" (we may even call this "model", right?) and only then there's
"arc-sdp" - which is the name we want to use for peripherals setup.

Checking for the 1-st sub-string in "compatible" property is not universal
for ARC. For simple one-entry "compatible" property it will return that one
entry which is fine, but for ARC SDP it will return 2 different values
depending on CPU-card being used:
 * "snps,axs101" or
 * "snps,axs103".

Checking for the 2nd entry in "compatible" property make no sense for all
boards except ARC SDP.

Checking for the last entry will work for all boards today, but I'm not
sure that there will be no other board with for example 3 entries from
which the one in the middle will make sense for OpenWRT.

So maybe solution would be in checking for a full match and doing the
same things for both "snps,axs101;snps,arc-sdp" and
"snps,axs103;snps,arc-sdp"?

I.e. something like this will work:
---------------->8---------------
	compatible="$( cat /proc/device-tree/compatible )"

	case "$compatible" in
	"snps,axs101""snps,arc-sdp")
		board="arc-sdp";
		;;
	"snps,nsim")
		board="arc-nsim";
		;;
	esac
---------------->8---------------

Any thoughts?

Note there's no "axs103" entry yet. I'll add it here in the following
patch series that adds support of ARCv2 architecture.

-Alexey
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel