2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@xxxxxxxx>: > On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote: > >> diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig >> new file mode 100644 >> index 0000000..112f470 >> --- /dev/null >> +++ b/arch/nds32/Kconfig >> @@ -0,0 +1,107 @@ >> +# >> +# For a description of the syntax of this configuration file, >> +# see Documentation/kbuild/kconfig-language.txt. >> +# >> + >> +config NDS32 >> + def_bool y >> + select ARCH_HAS_RAW_COPY_USER >> + select ARCH_WANT_FRAME_POINTERS if FTRACE >> + select ARCH_WANT_IPC_PARSE_VERSION >> + select CLKSRC_MMIO >> + select CLONE_BACKWARDS >> + select TIMER_OF >> + select FRAME_POINTER >> + select GENERIC_ATOMIC64 >> + select GENERIC_CPU_DEVICES >> + select GENERIC_CLOCKEVENTS >> + select GENERIC_IOMAP >> + select GENERIC_IRQ_CHIP >> + select GENERIC_IRQ_PROBE >> + select GENERIC_IRQ_SHOW >> + select GENERIC_STRNCPY_FROM_USER >> + select GENERIC_STRNLEN_USER >> + select GENERIC_TIME_VSYSCALL >> + select HAVE_ARCH_TRACEHOOK >> + select HAVE_GENERIC_IOMAP > > You normally don't want HAVE_GENERIC_IOMAP, at least unless the CPU > has special instructions to trigger PCI I/O port access. Thanks. I will remove it in the next version patch. >> + select HAVE_DEBUG_KMEMLEAK >> + select HAVE_IDE > > You certainly don't want HAVE_IDE Thanks. I will remove it in the next version patch. >> + select HAVE_MEMBLOCK >> + select HAVE_MEMBLOCK_NODE_MAP >> + select HAVE_UID16 > > HAVE_UID16 shouldn't be used on new architectures, as mentioned in the > comment about asm/posix_types.h Thanks. I will remove it in the next version patch. >> + select HAVE_REGS_AND_STACK_ACCESS_API >> + select IRQ_DOMAIN >> + select LOCKDEP_SUPPORT >> + select MODULES_USE_ELF_REL >> + select MODULES_USE_ELF_RELA > > I would think that you use either MODULES_USE_ELF_REL or > MODULES_USE_ELF_RELA, but not both. Thanks. I will check which one we used and remove the other one if posible. >> + select OF >> + select OF_EARLY_FLATTREE >> + select OLD_SIGACTION >> + select OLD_SIGSUSPEND3 > > What are the OLD_SIG* ones for? It sounds like something you shouldn't > need, although I'm not familiar wiht them. Thanks I will check if we need it or not. >> + select NO_IOPORT_MAP >> + select RTC_LIB >> + select THREAD_INFO_IN_TASK >> + select SYS_SUPPORTS_APM_EMULATION > > I don't see what SYS_SUPPORTS_APM_EMULATION gains you. Thanks. I will remove it in the next version patch. >> +config GENERIC_CALIBRATE_DELAY >> + def_bool y > > It's better to avoid the delay loop completely and skip the calibration, > if your hardware allows. Thanks. Do you mean that this config should be def_bool n? why? Almost all arch enable it. >> + >> +config NDS32_BUILTIN_DTB >> + string "Builtin DTB" >> + default "" >> + help >> + User can use it to specify the dts of the SoC > > Better leave this up to the boot loader. Thanks. uboot will pass it too. >> +config ALIGNMENT_TRAP >> + tristate "Kernel support unaligned access handling" >> + default y >> + help >> + Andes processors cannot fetch/store information which is not >> + naturally aligned on the bus, i.e., a 4 byte fetch must start at an >> + address divisible by 4. On 32-bit Andes processors, these non-aligned >> + fetch/store instructions will be emulated in software if you say >> + here, which has a severe performance impact. This is necessary for >> + correct operation of some network protocols. With an IP-only >> + configuration it is safe to say N, otherwise say Y. > > Which network protocols are you referring to? I will modify these descriptions. It was written by someone I don't know. :p This case only happened when I found is compiler code gen issue or wrong pointer usage. >> +config HIGHMEM >> + bool "High Memory Support" >> + depends on MMU && CPU_CACHE_NONALIASING >> + help >> + The address space of Andes processors is only 4 Gigabytes large >> + and it has to accommodate user address space, kernel address >> + space as well as some memory mapped IO. That means that, if you >> + have a large amount of physical memory and/or IO, not all of the >> + memory can be "permanently mapped" by the kernel. The physical >> + memory that is not permanently mapped is called "high memory". >> + >> + Depending on the selected kernel/user memory split, minimum >> + vmalloc space and actual amount of RAM, you may not need this >> + option which should result in a slightly faster kernel. >> + >> + If unsure, say N. > > Generally speaking, highmem support is a mess, and it's better to avoid it. > > I see that the two device tree files you have list 1GB of memory. Do you think > that is a common configuration for actual products? Do you expect any to > have more than 1GB (or more than 4GB) in the future, or is that the upper > end of the scale? > > If 1GB is a reasonable upper bound, then you could change the vmsplit > to give slightly less address space to user space and have 1GB of direct-mapped > kernel memory plus 256MB of vmalloc space reserved for the kernel, > and completely avoid highmem. Thanks. We do realy use 1GB ram in some products. We also verify CONFIG_HIGHMEM with LTP too. It seems fine but I will study vmsplit to see if we should use it. >> +config MEMORY_START >> + hex "Physical memory start address" >> + default "0x00000000" >> + help >> + Physical memory start address, you may modify it if it is porting to >> + a new SoC with different start address. >> +endmenu > > On ARM, we found options like this to be rather problematic since it prevents > you from running the same kernel on boards that are otherwise compatible. > > If the architecture easily allows the memory to start at address 0, could > you require this address for all SoCs that want to run Linux, and get > rid of the compile-time option? Thanks. The reason we need this config is because we need to define PHYS_OFFSET. #define PHYS_OFFSET (CONFIG_MEMORY_START) It needs to be set in compile-time. I don't know how to get rid of it.
