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

Tue Sep 8 08:52:33 EDT 2015

Hi Alexey,

On Fri, Sep 4, 2015 at 4:12 PM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> 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.

After thinking about this a bit more, I don't think we want an "arc"
target at all, as we neither have a "mips" or a "arm" target.

So I guess having axs10x nsim targets is the way to go (each with
arc700 and hs3x subtargets), as we usually model our targets after SoC
(families), not CPUs.

But I wonder, would it be possible to create a kernel that boots on
both nsim and axs10x, assuming one includes all required drivers and
both use the same cpu? I don't see anything preventing that in linux
4.2, apart from the ARC_HAS_COH_CACHES for SMP, which is true for HS3x
but isn't true for ARC700, but OTOH at least from a description ARC700
doesn't support SMP anyway. Differentiating both should be easy due to
devicetree, and reducing the required build targets to half would be
really nice.

>> 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 have one, unless you mean the multiplat target of arm. Also
note my usage of "guess" and "should" ;-p

>> 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.

So likely the ARC700 based SoC from AT&T and the tb10x SoCs would
become "toplevel" targets in the normal OpenWrt philosophy (unless
they are very similar), this would prevent any issues regarding
different MMU page sizes.

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