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

Jonas Gorski jogo at openwrt.org
Thu Sep 3 09:33:25 EDT 2015


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:
>> On Thu, Aug 27, 2015 at 1:03 PM, Alexey Brodkin
>> <Alexey.Brodkin at synopsys.com> wrote:
>> > This patch introduces support of new boards with ARC cores.
>> >
>> >  [1] Synopsys SDP board
>> >      This is a new-generation development board from Synopsys that
>> >      consists of base-board and CPU tile-board (which might have a real
>> >      ASIC or FPGA with CPU image).
>> >      It sports a lot of DesignWare peripherals like GMAC, USB, SPI, I2C
>> >      etc and is intended to be used for early development of ARC-based
>> >      products.
>> >
>> >  [2] nSIM
>> >      This is a virtual board implemented in Synopsys proprietary
>> >      software simulator (even though available for free for open source
>> >      community). This board has only serial port as a peripheral and so
>> >      it is meant to be used for runtime testing which is especially
>> >      useful during bring-up of new tools and platforms.
>> >      What's also important ARC cores are very configurable so there're
>> >      many variations of options like cache sizes, their line lengths,
>> >      additional hardware blocks like multipliers, dividers etc. And this
>> >      board could be used to make sure built software still runs on
>> >      different HW configurations.
>> >
>> > Note there's a prerequisite http://patchwork.ozlabs.org/patch/502081/
> [snip]
>> > diff --git a/target/linux/arc/axs10x/config-4.1 b/target/linux/arc/axs10x/config-4.1
>> > new file mode 100644
>> > index 0000000..2cd3471
>> > --- /dev/null
>> > +++ b/target/linux/arc/axs10x/config-4.1
>> > @@ -0,0 +1,127 @@
>> > +#
>> > +# ARC Architecture Configuration
>> > +#
>> Please run make kernel_{menu|old|def}config to make this configs
>> contain only the differences to the generic config.
> Hm... even though I see "kernel_menuconfig" and "kernel_oldconfig"
> targets exist in OpenWRT I cannot fing "kernel_defconfig". So I'm not sure
> if there's an automated way for creation of minimalistic defconfig that
> takes into account all levels of higher-level configs.

Right, kernel_defconfig doesn't exist, I always forget that. Buf
running kernel_oldconfig or kernel_menuconfig and saving should work
mostly the same way.

You can choose which config to modify with CONFIG_TARGET=platform for
the top target config and CONFIG_TARGET=subtarget for the subtarget.
The target config will be the difference to the generic config, and
the subtarget config will be then the difference to (generic +

> And kernel's "make savedefconfig" won't help here as well because
> lots of items will be stripped from defconfig and so OpenWRT on build will
> ask user to decide if this and that option should be on or off.
> I tried to create very minimal configs that still have all options covered
> on oldconfig.
> If there's a how-to or guide on hoe to prepare configs for OpenWRT target
> I'll try to conform its requirements.

There is no how-to, but if running make kernel_oldconfig for either
CONFIG_TARGET={platform|subtarget} results in no changed files, then
you did it right.

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

So I would use


and then


(You can have "toplevel" profiles that apply to all subtargets)

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list