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

Fri Sep 4 10:12:32 EDT 2015

Hi Jonas,

On Fri, 2015-09-04 at 15:44 +0200, Jonas Gorski wrote:
> Hi,
> 
> On Fri, Sep 4, 2015 at 1:24 PM, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> > 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?
> 
> Are the MMU page sizes hardcoded in the silicon/by pin strapping, or
> are they selectable at run time? Of course which are available likely
> depends on the core. But maybe there is a common one that's always
> available.

No this those options are selected during ASIC design process HW
engineer and then RTL gets built with hard-coded setting.
That said if MMU page size was set to 8k there's no way to either change
this value in runtime or somehow run kernel built for 4k or 16k pages.
Kernel will panic on early boot.

> Regarding the cache line sizes, this looks like a problem that should
> have already been solved for ARM, as they have a multiplat target,
> which I guess should be able to deal with varying cache line sizes.

Hm, interesting. May I have a pointer to it? 

> I don't think the OpenWrt images build with defaults must be optimized
> for all SoCs, just "run resonably well". If you need optimized for one
> you would then build and tweak yourself. But we do want to be able to
> build for as many boards as possible at the same time, to be able to
> at least compile test and allow easy runtime testing.

The thing is I'm not talking about optimization here.
As I explained above there're ARC core config options that require
Linux kernel to match them.

These are at least MMU page size and cache line length. If HW config
doesn't match kernel - kernel won't boot. And there's no solution for
that except proper kernel config.

Indeed there're other options like hardware multipliers of different
types, other additional HW blocks that might be used for getting
better performance. Those could be used but could be not used as well.
I.e. it's possible to build Linux kernel so it uses SW multiplication
instread of HW. That image will run on both ASICs with and without HW
multiplier.

But kernel built for 4k MMU page will only run on HW with the same
page size. The same is true for cache line size.

> And a final, not directly related question: where can one reasonably
> expect to enounter these SoCs? Are there or will there be any
> off-the-shelf devices where I can then flash OpenWrt onto?

Well I remember once we got a request from one hobbyist who
got WiFi router from AT&T and there was ARC700-based SoC. But
I cannot point you to that device now unfortunately.

Also we do know that ARC cores are used in networking equipment.
Good example is Abilis with their Abilis TB10x SoC, see
http://www.alitech.com/index.php/products/product/49/75.html

I'm not really sure where their SoC is used but it is very good
candidate for OpenWRT. And what's also good it is supported in
upstream Linux kernel.

So once we have basic OpenWRT port for ARC - for now with support
of our devboards - I'm pretty sure people will start putting it on their
devices.

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