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

[Alexey Brodkin]

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.

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