lkml.org 
[lkml]   [2013]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script
On Wednesday 07 November 2012 07:43 PM, Arnd Bergmann wrote:
> On Wednesday 07 November 2012, Vineet Gupta wrote:
>
>> +
>> +config ARC
>> + def_bool y
>> + select ARCH_WANT_IPC_PARSE_VERSION
>> + # ARC Busybox based initramfs absolutely relies on DEVTMPFS for /dev
>> + # DEVTMPS in turn needs HOTPLUG
>> + select DEVTMPFS if !INITRAMFS_SOURCE=""
>> + select GENERIC_ATOMIC64
>> + select GENERIC_CLOCKEVENTS
>> + select GENERIC_FIND_FIRST_BIT
>> + # for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
>> + select GENERIC_IRQ_SHOW
>> + select GENERIC_PENDING_IRQ if SMP
>> + select GENERIC_SMP_IDLE_THREAD
>> + select HAVE_GENERIC_HARDIRQS
>> + select HOTPLUG if !INITRAMFS_SOURCE=""
>> + select MODULES_USE_ELF_RELA
>
> You should not need ARCH_WANT_IPC_PARSE_VERSION

Done !

>> +# for old_[ug]id_t - do we need this ?
>> +config UID16
>> + def_bool y
>
> No, not needed either.

Done !

>
>> +menu "ARC Architecture Configuration"
>> +
>> +choice
>> + prompt "ARC Platform"
>> + default ARC_PLAT_FPGA_LEGACY
>> +
>> +config ARC_PLAT_FPGA_LEGACY
>> + bool "\"Legacy\" ARC FPGA dev platform"
>> + help
>> + Support for ARC development platforms, provided by Synopsys.
>> + These are based on FPGA or ISS. e.g.
>> + - ARCAngel4
>> + - ML509
>> + - MetaWare ISS
>> +
>> +#New platform adds here
>> +endchoice
>
> Platform selection should generally be non-exclusive. Just remove the
> "choice" statement here, and make sure that any platforms can be enabled
> together to build a single kernel.

So technically this is not in same league as usage of devicetree. Although it
seems to have it's own merits (single image, code coverage,..) but is this a hard
requirement for all arches. Here's my problem.

We have default implementations of clocksource using in-core local TIMER1. This
however might not suffice for some SMP ARC SoCs which need cross-core synchronized
timers. Obviously they want to use their own versions. In orig code (not v1 - but
in my new v2) I have a platform specific hook local_counter_setup() called from
time_init(). With #def PLAT1 and #def PLAT2, there could be 2 mutually exclusive
versions of those. With the "all-platform-build-together" paradigm, this simple
design is not possible - not to mention the needless code bloat for a simple run
in simulator. So now using devicetree, I first need to find what platform we are
on and then need to setup a platform specific function pointer (and same applies
to several other platform specific stuff). Is there a better way of doing this -
maybe the long dy has taken toll on me :-(


>> +menu "ARC CPU Configuration"
>> +
>> +choice
>> + prompt "ARC Core"
>> + default ARC_CPU_770
>> +
>> +config ARC_CPU_750D
>> + bool "ARC750D"
>> + help
>> + Support for ARC750 core
>> +
>> +config ARC_CPU_770
>> + bool "ARC770"
>> + select ARC_CPU_REL_4_10
>> + help
>> + Support for ARC770 core introduced with Rel 4.10 (Summer 2011)
>> + This core has a bunch of cool new features:
>> + -MMU-v3: Variable Page Sz (4k, 8k, 16k), bigger J-TLB (128x4)
>> + Shared Address Spaces (for sharing TLB entires in MMU)
>> + -Caches: New Prog Model, Region Flush
>> + -Insns: endian swap, load-locked/store-conditional, time-stamp-ctr
>> +
>> +endchoice
>
> Same thing here: If the different CPUs can in theory run the same kernel
> code, they should allow that. It doesn't stop you from making the default
> to enable only one of them and optimize for that case.

Background: ARC770 supports newer instructions (LOCK/SCOND) + MMUv3 which are not
available on ARC750. So code needs to be built differently for each. Having said
that above config items don't have any code under them - they are just high level
selectors for correct MMU versions and e.g. whether we allow the usage of new insns.

>
>> +
>> +choice
>> + prompt "ARC700 MMU Version"
>> + default ARC_MMU_V3 if ARC_CPU_770
>> + default ARC_MMU_V2 if ARC_CPU_750D
>> +
>
>> +endchoice
>
>> +choice
>> + prompt "MMU Page Size"
>> + default ARC_PAGE_SIZE_8K
>> +
>>
>> +
>> +endchoice
>
> For MMU, page size and endianess, I would not expect that to work though,
> so they probably need to remain mutually exclusive.

Ofcourse - given that PAGE_SIZE needs to be a compile time constant.

>
>> +menu "Platform Board Configuration"
>> +
>> +source "arch/arc/plat-arcfpga/Kconfig"
>> +#New platform adds here
>> +
>> +config ARC_PLAT_CLK
>> + int "Clk speed in Hz"
>> + default "80000000"
>> +
>> +config LINUX_LINK_BASE
>> + hex "Linux Link Address"
>> + default "0x80000000"
>> + help
>> + ARC700 divides the 32 bit phy address space into two equal halves
>> + -Lower 2G (0 - 0x7FFF_FFFF ) is user virtual, translated by MMU
>> + -Upper 2G (0x8000_0000 onwards) is untranslated, for kernel
>> + Typically Linux kernel is linked at the start of untransalted addr,
>> + hence the default value of 0x8zs.
>> + However some customers have peripherals mapped at this addr, so
>> + Linux needs to be scooted a bit.
>> + If you don't know what the above means, leave this setting alone.
>> +
>> +config ARC_PLAT_SDRAM_SIZE
>> + hex "SD RAM Size"
>> + default "0x10000000"
>> + help
>> + Implies the amount of SDRAM/DRAM Linux is going to claim/own.
>> + The actual memory itself could be larger than this number. But for
>> + all software purposes, this is the amt of memory.
>> +
>> +endmenu # "Platform Board Configuration"
>
> Clock speed and memory size are things that the kernel should normally
> be able to find out itself, if not from the hardware then from looking
> at the device tree binary that gets passed from the boot loader, or
> some other boot protocol that is already established.


Sure - both will come from devicetree. LINUX_LINK_BASE however is a fundamental
constant, used in linker script for final layout so it will have to be a .config item.

>
>> +if ARC_PLAT_FPGA_LEGACY
>> +
>> +choice
>> + prompt "FPGA Board"
>> +
>> +config ARC_BOARD_ANGEL4
>> + bool "ARC Angel4"
>> + help
>> + ARC Angel4 FPGA Ref Platform (Xilinx Virtex Based)
>> +
>> +config ARC_BOARD_ML509
>> + bool "ML509"
>> + help
>> + ARC ML509 FPGA Ref Platform (Xilinx Virtex-5 Based)
>> +
>> +endchoice
>
> Board files again should not be mutually exclusive.

OK ! Actually this hunk should not be present in initial upstream submission as
these only differ in a peripheral which is not yet submitted. This will be dropped.

>
> Arnd
>



\
 
 \ /
  Last update: 2013-01-02 16:01    [W:0.585 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site