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

Fri Sep 4 06:40:33 EDT 2015

Hi,

On Fri, Sep 4, 2015 at 12:35 PM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> Hi Jonas,
>
> On Fri, 2015-09-04 at 12:25 +0200, Jonas Gorski wrote:
>> Hi,
>>
>> On Thu, Sep 3, 2015 at 6:11 PM, Alexey Brodkin
>> <Alexey.Brodkin at synopsys.com> wrote:
>> > Hi Jonas,
>> >
>> > On Thu, 2015-09-03 at 15:33 +0200, Jonas Gorski wrote:
>> > > Hi,
>> > >
>> > > On Wed, Sep 2, 2015 at 10:40 PM, Alexey Brodkin
>> > > <Alexey.Brodkin at synopsys.com> wrote:
>> > > > Hi Jonas,
>> > > >
>> > > > On Wed, 2015-09-02 at 10:32 +0200, Jonas Gorski wrote:
>> > > > > Also please move
>> > > > > all common options from both subtargets into a
>> > > > > target/linux/arc/config-4.1.
>> > > >
>> > > > Well indeed there're same options in both configs.
>> > > > But please note nSIM and AXS10x are completely different boards.
>> > > > And each of those boards may have different CPU.
>> > > >
>> > > > This first set of patches only covers ARC legacy architecture (ARC 700).
>> > > >
>> > > > But with 4.2 release of Linux kernel new gen ARC architecture (ARC HS38)
>> > > > was introduced and once that patch set is accepted in OpenWRT I'll
>> > > > send another patch that add support of new gen ARC CPUs.
>> > > >
>> > > > My plan was to have following files structure:
>> > > >
>> > > > target/linux/arc/axs10x/profiles/arc700.mk
>> > > >                                 /archs38.mk
>> > > >                 /nsim/profiles/arc700.mk
>> > > >                               /archs38.mk
>> > > >
>> > > > Is it acceptable or I need to modify it?
>> > >
>> > > That seems backward, since arc700 and hs38 are different
>> > > architectures, so I would assume their kernels and toolchains won't be
>> > > compatible.
>> > >
>> > > So I would use
>> > >
>> > > target/linuxarc/arc700
>> > > and
>> > > target/linux/arc/hs38
>> > >
>> > > and then
>> > >
>> > > target/linux/arc/profiles/axs10x.mk
>> > > and
>> > > target/linux/arc/profiles/nsim.mk
>> > >
>> > > (You can have "toplevel" profiles that apply to all subtargets)
>> >
>> > Well I don't understand how that will work.
>> > I mean we need to have different:
>> >  [1] kernel config options for both pairs: boards (axs10x vs nsim)
>> >      and architectures (arcv1 vs arcv2)
>> >  [2] basefiles for boards (axs10x vs nsim)
>> >
>> > I.e. setting profiles for axs10x and nsim won't be enough.
>> >
>> > Maybe this all is not very clear, so I'll try to put here what we need to accommodate:
>> >  [1] For axs10x board:
>> >     a) base files for axs10x board
>> >     b) kernel options for axs10x board
>> >     c) kernel options for arc700 core in axs10x
>> >     d) kernel options for archs38 core in axs10x
>> >
>> >  [2] For nsim board:
>> >     a) base files for nsim board
>> >     b) kernel options for nsim board
>> >     c) kernel options for arc700
>> > core in nsim
>> >     d) kernel options for archs38 core in nsim
>> >
>> > So maybe the only option that will work is having 2 top-level arc entries like:
>> >  * target/linux/arcv1 (or arc700)
>> >  * target/linux/arcv2 (or archs38)
>> >
>> > Or another alternative is 4 subtargets like that (I see something similar for RPi,
>> > see target/linux/brcm2708):
>>
>> brcm2708 does this because bcm2709 supports a newer arm instruction
>> set, so to not be limited by the older one we split it into 2708 and
>> 2709. If they both supported the same arm version, then there would be
>> no need for subtargets.
>>
>> >  * target/linux/axs101 (which is axs10x with arc700)
>> >  * target/linux/axs103 (which is axs10x with archs38)
>> >  * target/linux/nsim_700 (which is nsim with arc700)
>> >  * target/linux/nsim_hs (which is nsim with archs38)
>> >
>> > But that in its turn will require to duplicate basefiles and kernel configs
>> > relevant to boards but not cores.
>> >
>> > Any thoughts about that are much appreciated.
>>
>> Unfortunately that is not how OpenWrt is supposed to work. The
>> expectation is that a (sub)target is for all boards that share a
>> certain (family of) SoCs, not just a single board. Looking at Linux
>> 4.2, you are using device tree, so I would assume it would be possible
>> to build a kenrel that "supports" all boards with a arc700 cpu,
>> through passing the appropriate dtb to it. And likewise for the hs38.
>> If the bootloader does not support passing a dtb, then it maybe
>> appending a dtb like on ARM would be an option; or reserving  space in
>> the kernel to patch in a dtb (we have a patch for MIPS for that, but
>> that would likely work similar for other targets).
>>
>> Having a subtarget for each board will create a huge burden for
>> release builds, es effectively we will then need to build a new
>> toolchain for each board, and they cannot share their packages feeds,
>> so we would also need to rebuild all packages for all boards.
>>
>> So please rework your target to not use/require per-board subtargets.
>
> Sorry for another round of questions but from your answer I still
> don't understand what my source tree should look like?
>
> 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.

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