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

[Jonas Gorski]

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.

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.

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.

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?


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