Hi, On Fri, Sep 4, 2015 at 12:35 PM, Alexey Brodkin <alexey.brod...@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.brod...@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.brod...@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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
