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

Alexey Brodkin Alexey.Brodkin at synopsys.com
Fri Sep 4 06:45:10 EDT 2015


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

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")

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



More information about the openwrt-devel mailing list