Hi Alexey, On Fri, Sep 4, 2015 at 4:12 PM, Alexey Brodkin <alexey.brod...@synopsys.com> wrote: > Hi Jonas, > > On Fri, 2015-09-04 at 15:44 +0200, Jonas Gorski wrote: >> Hi, >> >> On Fri, Sep 4, 2015 at 1:24 PM, Alexey Brodkin >> <alexey.brod...@synopsys.com> wrote: >> > Hi Jonas, >> > >> > On Fri, 2015-09-04 at 13:01 +0200, Jonas Gorski wrote: >> > > On Fri, Sep 4, 2015 at 12:45 PM, Alexey Brodkin >> > > <alexey.brod...@synopsys.com> wrote: >> > > > 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 >> > > > > > 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") >> > > >> > > Boards usually don't have their own directories, you would define >> > > profiles in target/linux/arc/<subtarget>/profiles. These are usually >> > > grouped by manufacturer, so a synopsis.mk would contain all >> > > reference/development boards directly offered by you. It is also >> > > common to provide a "Default" / "Generic" profile for building all >> > > boards at once, which has a reasonable set of packages (mostly kmods) >> > > to include that cover the most common devices found on the boards >> > > (e.g. if most boards have usb, it should include the usb modules etc). >> > > >> > > Within your target/linux/arc/base-files you would use a runtime >> > > detection mechanism for determining the board at first boot to >> > > generate an appropriate network config etc. Since you are using device >> > > tree, you can easily use /proc/device-tree/model (or compatible) for >> > > identifying the board you are running on. >> > > >> > > The most recent iteration of setup-default-config uses >> > > base-files/etc/board.d/ (see ramips), and the most common is setting >> > > up through base-files/etc/uci-defaults/ scripts. I can't really give >> > > you much information about the former, since I haven't used it myself. >> > >> > Thanks for the pointer, I'll play with that dynamic setup of board >> > things and .dts patching. >> > >> > Still I have one question unsolved. >> > ARC architecture is very configurable, i.e. there could be >> > arc700-based SoC with MMU page 4, 8 or 16 kB or cache line length >> > typically of 32 or 64 bytes. >> > >> > And unfortunately .dts doesn't help here because those values >> > a defined during kernel configuration and then become built-ins. >> > >> > I.e. I need to have a way to use a bit different kernel config for >> > each board. Well it's not really required for all boards to have >> > different configs - at least within Synopsys we try to keep configs >> > aligned between platforms but tomorrow new board will appear with >> > different core settings and I'd like to be prepared to it. >> > >> > Any thoughts on how to solve it properly in OpenWRT? >> >> Are the MMU page sizes hardcoded in the silicon/by pin strapping, or >> are they selectable at run time? Of course which are available likely >> depends on the core. But maybe there is a common one that's always >> available. > > No this those options are selected during ASIC design process HW > engineer and then RTL gets built with hard-coded setting. > That said if MMU page size was set to 8k there's no way to either change > this value in runtime or somehow run kernel built for 4k or 16k pages. > Kernel will panic on early boot.
After thinking about this a bit more, I don't think we want an "arc" target at all, as we neither have a "mips" or a "arm" target. So I guess having axs10x nsim targets is the way to go (each with arc700 and hs3x subtargets), as we usually model our targets after SoC (families), not CPUs. But I wonder, would it be possible to create a kernel that boots on both nsim and axs10x, assuming one includes all required drivers and both use the same cpu? I don't see anything preventing that in linux 4.2, apart from the ARC_HAS_COH_CACHES for SMP, which is true for HS3x but isn't true for ARC700, but OTOH at least from a description ARC700 doesn't support SMP anyway. Differentiating both should be easy due to devicetree, and reducing the required build targets to half would be really nice. >> Regarding the cache line sizes, this looks like a problem that should >> have already been solved for ARM, as they have a multiplat target, >> which I guess should be able to deal with varying cache line sizes. > > Hm, interesting. May I have a pointer to it? I don't have one, unless you mean the multiplat target of arm. Also note my usage of "guess" and "should" ;-p >> And a final, not directly related question: where can one reasonably >> expect to enounter these SoCs? Are there or will there be any >> off-the-shelf devices where I can then flash OpenWrt onto? > > Well I remember once we got a request from one hobbyist who > got WiFi router from AT&T and there was ARC700-based SoC. But > I cannot point you to that device now unfortunately. > > Also we do know that ARC cores are used in networking equipment. > Good example is Abilis with their Abilis TB10x SoC, see > http://www.alitech.com/index.php/products/product/49/75.html > > I'm not really sure where their SoC is used but it is very good > candidate for OpenWRT. And what's also good it is supported in > upstream Linux kernel. > > So once we have basic OpenWRT port for ARC - for now with support > of our devboards - I'm pretty sure people will start putting it on their > devices. So likely the ARC700 based SoC from AT&T and the tb10x SoCs would become "toplevel" targets in the normal OpenWrt philosophy (unless they are very similar), this would prevent any issues regarding different MMU page sizes. Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
