[OpenWrt-Devel] [PATCH 3/3] linux: add support of Synopsys ARC boards

[Alexey Brodkin]

Hi Jonas,

On Fri, 2015-09-04 at 13:01 +0200, Jonas Gorski wrote:
> On Fri, Sep 4, 2015 at 12:45 PM, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> > Hi Jonas,
> > 
> > On Fri, 2015-09-04 at 12:40 +0200, Jonas Gorski wrote:
> > > Hi,
> > > 
> > > On Fri, Sep 4, 2015 at 12:35 PM, Alexey Brodkin
> > > > If one of my proposals above ok?
> > > > For example this one?
> > > > ------->8--------
> > > >  * target/linux/arcv1 (or arc700)
> > > >  * target/linux/arcv2 (or archs38)
> > > > ------->8--------
> > > > 
> > > > In this scheme we do have different architectures with incompatible
> > > > tools and binaries.
> > > 
> > > Right, although I would think
> > > 
> > > target/linux/arc/arcv1/
> > > target/linux/arc/arcv2/
> > > 
> > > would be better, as surely they will share all the driver options, and
> > > only differ in the selected cpu. Also that would mean you/we only have
> > > one set of kernel patches to maintain.
> > 
> > Agree.
> > So then what about boards? Where should they be placed in this hierarchy?
> > Will it be something like that?
> > 
> >  * target/linux/arc/arcv1/axs101 (or "axs10x" for uniformity)
> >                          /nsim_700 (or "nsim" for uniformity)
> >  * target/linux/arc/arcv2/axs103 (or "axs10x")
> >                          /nsim_hs (or "nsim")
> 
> Boards usually don't have their own directories, you would define
> profiles in target/linux/arc/<subtarget>/profiles. These are usually
> grouped by manufacturer, so a synopsis.mk would contain all
> reference/development boards directly offered by you. It is also
> common to provide a "Default" / "Generic" profile for building all
> boards at once, which has a reasonable set of packages (mostly kmods)
> to include that cover the most common devices found on the boards
> (e.g. if most boards have usb, it should include the usb modules etc).
> 
> Within your target/linux/arc/base-files you would use a runtime
> detection mechanism for determining the board at first boot to
> generate an appropriate network config etc. Since you are using device
> tree, you can easily use /proc/device-tree/model (or compatible) for
> identifying the board you are running on.
> 
> The most recent iteration of setup-default-config uses
> base-files/etc/board.d/ (see ramips), and the most common is setting
> up through base-files/etc/uci-defaults/ scripts. I can't really give
> you much information about the former, since I haven't used it myself.

Thanks for the pointer, I'll play with that dynamic setup of board
things and .dts patching.

Still I have one question unsolved.
ARC architecture is very configurable, i.e. there could be
arc700-based SoC with MMU page 4, 8 or 16 kB or cache line length
typically of 32 or 64 bytes.

And unfortunately .dts doesn't help here because those values
a defined during kernel configuration and then become built-ins.

I.e. I need to have a way to use a bit different kernel config for
each board. Well it's not really required for all boards to have
different configs - at least within Synopsys we try to keep configs
aligned between platforms but tomorrow new board will appear with
different core settings and I'd like to be prepared to it.

Any thoughts on how to solve it properly in OpenWRT?

-Alexey

P.S. Yes, I know that super-configurability is a bit of pain when it comes
to support it but that's how we differentiate ourselves from others and
so we have to support it, otherwise why make that different hardware? :)
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel