| Message ID | 7278eca76456b412e02d9baa5dc164e83199cbab.1510118606.git.green.hu@gmail.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | Andes(nds32) Linux Kernel Port | expand |
On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> 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. > + select HAVE_DEBUG_KMEMLEAK > + select HAVE_IDE You certainly don't want HAVE_IDE > + 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 > + 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. > + 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. > + 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. > +config GENERIC_CALIBRATE_DELAY > + def_bool y It's better to avoid the delay loop completely and skip the calibration, if your hardware allows. > + > +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. > +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? > +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. > +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? Arnd
2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: > On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> 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.
On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu <green.hu@gmail.com> wrote: > 2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote: >>> +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. It depends on what your hardware can do. If you have a way to see how much time has passed that is guaranteed to be reliable on all machines, then use that instead. On a lot of architectures, it's not possible, so they have to fall back to using the delay loop. >>> +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. Ok, should it also be 'default n' then? >>> +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. For the 1GB configuration, something like ARM's CONFIG_VMSPLIT_3G_OPT should be optimal, it will result in better performance because it allows you to completely turn off CONFIG_HIGHMEM. The reason we don't always use it on ARM is that traditionally we had the 3GB vmsplit, and some applications might rely on having the exact amount of available address space that they expect. For a new architecture that should be less of a problem. The interesting case is what happens if you have machines with 1.5GB or or more physical RAM. You can obviously have another vmsplit configuration for those, but at some point going to highmem is better than limiting the user address space. Ideally 1.5GB is the point where you start using a 64-bit CPU, but of course that is not something you have available at the moment. >>> +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. PHYS_OFFSET doesn't have to be a constant, a lot of architectures make the __va()/__pa() and related functions use a variable for the offset. This is also useful to implement KASLR, and booting the kernel from a random physical address. My actual suggestion however was to just mandate that PHYS_OFFSET is always zero for your architecture, and not support any other value. This is easy as long as you don't have existing hardware that would break. Arnd
2017-11-09 18:33 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: > On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu <green.hu@gmail.com> wrote: >> 2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote: > >>>> +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. > > It depends on what your hardware can do. If you have a way to see how much > time has passed that is guaranteed to be reliable on all machines, then > use that instead. > > On a lot of architectures, it's not possible, so they have to fall back to using > the delay loop. I get it. I will discuss it with our HW colleagues. We may get these informations in some registers. >>>> +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. > > Ok, should it also be 'default n' then? Yup. I will use 'default n' in the next version patch. >>>> +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. > > For the 1GB configuration, something like ARM's CONFIG_VMSPLIT_3G_OPT > should be optimal, it will result in better performance because it allows you > to completely turn off CONFIG_HIGHMEM. The reason we don't always > use it on ARM is that traditionally we had the 3GB vmsplit, and some > applications > might rely on having the exact amount of available address space that they > expect. For a new architecture that should be less of a problem. > > The interesting case is what happens if you have machines with 1.5GB or > or more physical RAM. You can obviously have another vmsplit configuration > for those, but at some point going to highmem is better than limiting the > user address space. > > Ideally 1.5GB is the point where you start using a 64-bit CPU, but of course > that is not something you have available at the moment. >>>> +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. > > PHYS_OFFSET doesn't have to be a constant, a lot of architectures make > the __va()/__pa() and related functions use a variable for the offset. > This is also useful to implement KASLR, and booting the kernel from > a random physical address. > > My actual suggestion however was to just mandate that PHYS_OFFSET > is always zero for your architecture, and not support any other value. > This is easy as long as you don't have existing hardware that would > break. Thanks. I will check how other architectures do. I can mandate that PHYS_OFFSET is zero but our customers(SoC company) may not use 0x0 as default DRAM starting address. This assumption is a little bit too strong.
On Wed, Nov 8, 2017 at 11:16 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote: >> --- /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. GENERIC_IOMAP or HAVE_GENERIC_IOMAP? The latter doesn't even exist, except in Documentation/kbuild/kconfig-language.txt, so it cannot be selected. Given the checks for __NDS32_EB__, NDS32 can be either big or little endian, so you should have (excatly one of) CPU_BIG_ENDIAN or CPU_LITTLE_ENDIAN set. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
2017-11-13 18:45 GMT+08:00 Geert Uytterhoeven <geert@linux-m68k.org>: > On Wed, Nov 8, 2017 at 11:16 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote: >>> --- /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. > > GENERIC_IOMAP or HAVE_GENERIC_IOMAP? > > The latter doesn't even exist, except in > Documentation/kbuild/kconfig-language.txt, so it cannot be selected. Thanks. I will remove HAVE_GENERIC_IOMAP in the next version patch. > Given the checks for __NDS32_EB__, NDS32 can be either big or little endian, > so you should have (excatly one of) CPU_BIG_ENDIAN or CPU_LITTLE_ENDIAN set. Thanks. I will check if we need this config or not and update in the next version patch.
On Thu, Nov 16, 2017 at 11:03 AM, Greentime Hu <green.hu@gmail.com> wrote: > 2017-11-13 18:45 GMT+08:00 Geert Uytterhoeven <geert@linux-m68k.org>: >> Given the checks for __NDS32_EB__, NDS32 can be either big or little endian, >> so you should have (excatly one of) CPU_BIG_ENDIAN or CPU_LITTLE_ENDIAN set. > > Thanks. > I will check if we need this config or not and update in the next version patch. I think we have one architecture in the kernel that determines endianess from the way that the toolchain is built. What all the others do it to have a Kconfig option, at least CONFIG_CPU_BIG_ENDIAN that is used to pass -mbig-endian or -mlittle-endian to the compiler. You should do it that way so you can use any toolchain with any kernel configuration. Arnd
2017-11-10 16:26 GMT+08:00 Greentime Hu <green.hu@gmail.com>: > 2017-11-09 18:33 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >> On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu <green.hu@gmail.com> wrote: >>> 2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >>>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote: >> >>>>> +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. >> >> It depends on what your hardware can do. If you have a way to see how much >> time has passed that is guaranteed to be reliable on all machines, then >> use that instead. >> >> On a lot of architectures, it's not possible, so they have to fall back to using >> the delay loop. > > I get it. I will discuss it with our HW colleagues. > We may get these informations in some registers. Hi, Arnd: I think I can't set it to default n because it will be called in start_kernel. start_kernel() -> calibrate_delay() If I don't enable this config, it will link error because it didn't build init/calibrate.c
On Fri, Nov 17, 2017 at 1:39 PM, Greentime Hu <green.hu@gmail.com> wrote: > 2017-11-10 16:26 GMT+08:00 Greentime Hu <green.hu@gmail.com>: >> 2017-11-09 18:33 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >>> On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu <green.hu@gmail.com> wrote: >>>> 2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >>>>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote: >>> >>>>>> +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. >>> >>> It depends on what your hardware can do. If you have a way to see how much >>> time has passed that is guaranteed to be reliable on all machines, then >>> use that instead. >>> >>> On a lot of architectures, it's not possible, so they have to fall back to using >>> the delay loop. >> >> I get it. I will discuss it with our HW colleagues. >> We may get these informations in some registers. > > Hi, Arnd: > > I think I can't set it to default n because it will be called in start_kernel. > > start_kernel() -> calibrate_delay() > > If I don't enable this config, it will link error because it didn't > build init/calibrate.c You will have to provide an architecture-specific implementation of this function, please ahve a look at what others are doing, e.g. tile, openrisc or h8300. Arnd
2017-11-17 20:50 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: > On Fri, Nov 17, 2017 at 1:39 PM, Greentime Hu <green.hu@gmail.com> wrote: >> 2017-11-10 16:26 GMT+08:00 Greentime Hu <green.hu@gmail.com>: >>> 2017-11-09 18:33 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >>>> On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu <green.hu@gmail.com> wrote: >>>>> 2017-11-08 18:16 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: >>>>>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote: >>>> >>>>>>> +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. >>>> >>>> It depends on what your hardware can do. If you have a way to see how much >>>> time has passed that is guaranteed to be reliable on all machines, then >>>> use that instead. >>>> >>>> On a lot of architectures, it's not possible, so they have to fall back to using >>>> the delay loop. >>> >>> I get it. I will discuss it with our HW colleagues. >>> We may get these informations in some registers. >> >> Hi, Arnd: >> >> I think I can't set it to default n because it will be called in start_kernel. >> >> start_kernel() -> calibrate_delay() >> >> If I don't enable this config, it will link error because it didn't >> build init/calibrate.c > > You will have to provide an architecture-specific implementation of > this function, please ahve a look at what others are doing, e.g. tile, > openrisc or > h8300. Thanks. I got you.
2017-11-16 18:25 GMT+08:00 Arnd Bergmann <arnd@arndb.de>: > On Thu, Nov 16, 2017 at 11:03 AM, Greentime Hu <green.hu@gmail.com> wrote: >> 2017-11-13 18:45 GMT+08:00 Geert Uytterhoeven <geert@linux-m68k.org>: >>> Given the checks for __NDS32_EB__, NDS32 can be either big or little endian, >>> so you should have (excatly one of) CPU_BIG_ENDIAN or CPU_LITTLE_ENDIAN set. >> >> Thanks. >> I will check if we need this config or not and update in the next version patch. > > I think we have one architecture in the kernel that determines endianess from > the way that the toolchain is built. What all the others do it to have a Kconfig > option, at least CONFIG_CPU_BIG_ENDIAN that is used to pass -mbig-endian > or -mlittle-endian to the compiler. You should do it that way so you can use > any toolchain with any kernel configuration. Thanks I will add these 2 configs in the next version patch. Pass -EL or -EB to compiler based on different configs.
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 + select HAVE_DEBUG_KMEMLEAK + select HAVE_IDE + select HAVE_MEMBLOCK + select HAVE_MEMBLOCK_NODE_MAP + select HAVE_UID16 + select HAVE_REGS_AND_STACK_ACCESS_API + select IRQ_DOMAIN + select LOCKDEP_SUPPORT + select MODULES_USE_ELF_REL + select MODULES_USE_ELF_RELA + select OF + select OF_EARLY_FLATTREE + select OLD_SIGACTION + select OLD_SIGSUSPEND3 + select NO_IOPORT_MAP + select RTC_LIB + select THREAD_INFO_IN_TASK + select SYS_SUPPORTS_APM_EMULATION + help + Andes(nds32) Linux support. + +config GENERIC_CALIBRATE_DELAY + def_bool y + +config GENERIC_CSUM + def_bool y + +config GENERIC_HWEIGHT + def_bool y + +config GENERIC_LOCKBREAK + def_bool y + depends on PREEMPT + +config RWSEM_GENERIC_SPINLOCK + def_bool y + +config TRACE_IRQFLAGS_SUPPORT + def_bool y + +config STACKTRACE_SUPPORT + def_bool y + +config PGTABLE_LEVELS + default 2 + +source "init/Kconfig" + +menu "System Type" +source "arch/nds32/Kconfig.cpu" +config NR_CPUS + int + default 1 + +config MMU + def_bool y + +config NDS32_BUILTIN_DTB + string "Builtin DTB" + default "" + help + User can use it to specify the dts of the SoC +endmenu + +menu "Kernel Features" +source "kernel/Kconfig.preempt" +source "mm/Kconfig" +source "kernel/Kconfig.hz" +endmenu + +menu "Executable file formats" +source "fs/Kconfig.binfmt" +endmenu + +source "net/Kconfig" +source "drivers/Kconfig" +source "fs/Kconfig" +source "arch/nds32/Kconfig.debug" +source "security/Kconfig" +source "crypto/Kconfig" +source "lib/Kconfig" diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu new file mode 100644 index 0000000..40eaa97 --- /dev/null +++ b/arch/nds32/Kconfig.cpu @@ -0,0 +1,100 @@ +comment "Processor Features" +config HWZOL + bool "hardware zero overhead loop support" + default y + help + A set of Zero-Overhead Loop mechanism is provided to reduce the + instruction fetch and execution overhead of loop-control instructions. + It will save 3 registers($LB, $LC, $LE) for context saving if say Y. + You don't need to save these registers if you can make sure your user + program doesn't use these registers. + + If unsure, say N. + +config CPU_CACHE_NONALIASING + bool "Non-aliasing cache" + help + If this CPU is using VIPT data cache and its cache way size is larger + than page size, say N. If it is using PIPT data cache, say Y. + + If unsure, say Y. + +choice + prompt "Paging -- page size " + default ANDES_PAGE_SIZE_4KB +config ANDES_PAGE_SIZE_4KB + bool "use 4KB page size" +config ANDES_PAGE_SIZE_8KB + bool "use 8KB page size" +endchoice + +config CPU_ICACHE_DISABLE + bool "Disable I-Cache" + help + Say Y here to disable the processor instruction cache. Unless + you have a reason not to or are unsure, say N. + +config CPU_DCACHE_DISABLE + bool "Disable D-Cache" + help + Say Y here to disable the processor data cache. Unless + you have a reason not to or are unsure, say N. + +config CPU_DCACHE_WRITETHROUGH + bool "Force write through D-cache" + depends on !CPU_DCACHE_DISABLE + help + Say Y here to use the data cache in writethrough mode. Unless you + specifically require this or are unsure, say N. + +config WBNA + bool "WBNA" + default n + help + Say Y here to enable write-back memory with no-write-allocation policy. + +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. + +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. + +config CACHE_L2 + bool "Support L2 cache" + default y + help + Say Y here to enable L2 cache if your SoC are integrated with L2CC. + If unsure, say N. + +menu "Memory configuration" + +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 diff --git a/arch/nds32/Kconfig.debug b/arch/nds32/Kconfig.debug new file mode 100644 index 0000000..665da0a --- /dev/null +++ b/arch/nds32/Kconfig.debug @@ -0,0 +1,14 @@ +menu "Kernel hacking" + +source "lib/Kconfig.debug" + +config EARLY_PRINTK + bool "Early printk support" + default y + help + Say Y here if you want to have an early console using the + earlyprintk=<name>[,<addr>][,<options>] kernel parameter. It + is assumed that the early console device has been initialised + by the boot loader prior to starting the Linux kernel. + +endmenu diff --git a/arch/nds32/Makefile b/arch/nds32/Makefile new file mode 100644 index 0000000..1bef714 --- /dev/null +++ b/arch/nds32/Makefile @@ -0,0 +1,60 @@ +LDFLAGS_vmlinux := --no-undefined -X +OBJCOPYFLAGS := -O binary -R .note -R .note.gnu.build-id -R .comment -S + +KBUILD_DEFCONFIG := ae3xx_defconfig + +comma = , + +KBUILD_CFLAGS +=-mno-sched-prolog-epilog -mcmodel=large + +KBUILD_CFLAGS +=$(arch-y) $(tune-y) +KBUILD_AFLAGS +=$(arch-y) $(tune-y) + +#Default value +head-y := arch/nds32/kernel/head.o +textaddr-y := 0xc000c000 + +TEXTADDR := $(textaddr-y) + +export TEXTADDR + + +# If we have a machine-specific directory, then include it in the build. +core-y += arch/nds32/kernel/ arch/nds32/mm/ +libs-y += arch/nds32/lib/ +LIBGCC_PATH := \ + $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name) +libs-y += $(LIBGCC_PATH) + +ifneq '$(CONFIG_NDS32_BUILTIN_DTB)' '""' +BUILTIN_DTB := y +else +BUILTIN_DTB := n +endif + +boot := arch/nds32/boot +core-$(BUILTIN_DTB) += $(boot)/dts/ + +.PHONY: FORCE + +Image: vmlinux + $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ + + +PHONY += vdso_install +vdso_install: + $(Q)$(MAKE) $(build)=arch/nds32/kernel/vdso $@ + +prepare: vdso_prepare +vdso_prepare: prepare0 + $(Q)$(MAKE) $(build)=arch/nds32/kernel/vdso include/generated/vdso-offsets.h + +CLEAN_FILES += include/asm-nds32/constants.h* + +# We use MRPROPER_FILES and CLEAN_FILES now +archclean: + $(Q)$(MAKE) $(clean)=$(boot) + +define archhelp + echo ' Image - kernel image (arch/$(ARCH)/boot/Image)' +endef diff --git a/arch/nds32/boot/Makefile b/arch/nds32/boot/Makefile new file mode 100644 index 0000000..3f9b86f --- /dev/null +++ b/arch/nds32/boot/Makefile @@ -0,0 +1,15 @@ +targets := Image Image.gz + +$(obj)/Image: vmlinux FORCE + $(call if_changed,objcopy) + +$(obj)/Image.gz: $(obj)/Image FORCE + $(call if_changed,gzip) + +install: $(obj)/Image + $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \ + $(obj)/Image System.map "$(INSTALL_PATH)" + +zinstall: $(obj)/Image.gz + $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \ + $(obj)/Image.gz System.map "$(INSTALL_PATH)" diff --git a/arch/nds32/include/asm/Kbuild b/arch/nds32/include/asm/Kbuild new file mode 100644 index 0000000..414ca9d --- /dev/null +++ b/arch/nds32/include/asm/Kbuild @@ -0,0 +1,54 @@ +generic-y += asm-offsets.h +generic-y += atomic.h +generic-y += barrier.h +generic-y += bitops.h +generic-y += bitsperlong.h +generic-y += bug.h +generic-y += bugs.h +generic-y += checksum.h +generic-y += clkdev.h +generic-y += cmpxchg.h +generic-y += cmpxchg-local.h +generic-y += cputime.h +generic-y += device.h +generic-y += div64.h +generic-y += dma.h +generic-y += emergency-restart.h +generic-y += errno.h +generic-y += exec.h +generic-y += fb.h +generic-y += fcntl.h +generic-y += ftrace.h +generic-y += gpio.h +generic-y += hardirq.h +generic-y += hw_irq.h +generic-y += ioctl.h +generic-y += ioctls.h +generic-y += irq.h +generic-y += irq_regs.h +generic-y += irq_work.h +generic-y += kdebug.h +generic-y += kmap_types.h +generic-y += kprobes.h +generic-y += kvm_para.h +generic-y += limits.h +generic-y += local.h +generic-y += mm-arch-hooks.h +generic-y += mman.h +generic-y += parport.h +generic-y += pci.h +generic-y += percpu.h +generic-y += preempt.h +generic-y += sections.h +generic-y += segment.h +generic-y += serial.h +generic-y += shmbuf.h +generic-y += sizes.h +generic-y += stat.h +generic-y += switch_to.h +generic-y += timex.h +generic-y += topology.h +generic-y += trace_clock.h +generic-y += unaligned.h +generic-y += user.h +generic-y += word-at-a-time.h diff --git a/arch/nds32/include/uapi/asm/Kbuild b/arch/nds32/include/uapi/asm/Kbuild new file mode 100644 index 0000000..c3911f5 --- /dev/null +++ b/arch/nds32/include/uapi/asm/Kbuild @@ -0,0 +1,26 @@ +# UAPI Header export list +include include/uapi/asm-generic/Kbuild.asm + +generic-y += errno.h +generic-y += ioctl.h +generic-y += ioctls.h +generic-y += ipcbuf.h +generic-y += shmbuf.h +generic-y += bitsperlong.h +generic-y += fcntl.h +generic-y += stat.h +generic-y += mman.h +generic-y += msgbuf.h +generic-y += poll.h +generic-y += resource.h +generic-y += sembuf.h +generic-y += setup.h +generic-y += siginfo.h +generic-y += socket.h +generic-y += sockios.h +generic-y += swab.h +generic-y += statfs.h +generic-y += termbits.h +generic-y += termios.h +generic-y += types.h +generic-y += ucontext.h diff --git a/arch/nds32/kernel/Makefile b/arch/nds32/kernel/Makefile new file mode 100644 index 0000000..5abcb0d --- /dev/null +++ b/arch/nds32/kernel/Makefile @@ -0,0 +1,24 @@ +# +# Makefile for the linux kernel. +# + +CPPFLAGS_vmlinux.lds := -DTEXTADDR=$(TEXTADDR) +AFLAGS_head.o := -DTEXTADDR=$(TEXTADDR) + +# Object file lists. + +obj-y := ex-entry.o ex-exit.o ex-scall.o irq.o \ + process.o ptrace.o setup.o signal.o \ + sys_nds32.o time.o traps.o cacheinfo.o \ + dma.o syscall_table.o vdso.o + +obj-$(CONFIG_MODULES) += nds32_ksyms.o module.o +obj-$(CONFIG_STACKTRACE) += stacktrace.o +obj-$(CONFIG_OF) += devtree.o +obj-$(CONFIG_EARLY_PRINTK) += early_printk.o +obj-$(CONFIG_CACHE_L2) += atl2c.o + +extra-y := head.o vmlinux.lds + + +obj-y += vdso/ diff --git a/arch/nds32/kernel/vmlinux.lds.S b/arch/nds32/kernel/vmlinux.lds.S new file mode 100644 index 0000000..2b1e55d --- /dev/null +++ b/arch/nds32/kernel/vmlinux.lds.S @@ -0,0 +1,70 @@ +/* + * Copyright (C) 2005-2017 Andes Technology Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>. + */ + +#include <asm/page.h> +#include <asm/thread_info.h> +#include <asm/cache.h> +#include <asm/memory.h> + +#define LOAD_OFFSET (PAGE_OFFSET - PHYS_OFFSET) +#include <asm-generic/vmlinux.lds.h> + +OUTPUT_ARCH(nds32) +ENTRY(_stext_lma) +jiffies = jiffies_64; + +SECTIONS +{ + _stext_lma = TEXTADDR - LOAD_OFFSET; + . = TEXTADDR; + __init_begin = .; + HEAD_TEXT_SECTION + INIT_TEXT_SECTION(PAGE_SIZE) + INIT_DATA_SECTION(16) + PERCPU_SECTION(L1_CACHE_BYTES) + __init_end = .; + + . = ALIGN(PAGE_SIZE); + _stext = .; + /* Real text segment */ + .text : AT(ADDR(.text) - LOAD_OFFSET) { + _text = .; /* Text and read-only data */ + TEXT_TEXT + SCHED_TEXT + CPUIDLE_TEXT + LOCK_TEXT + KPROBES_TEXT + IRQENTRY_TEXT + *(.fixup) + } + + _etext = .; /* End of text and rodata section */ + + _sdata = .; + RO_DATA_SECTION(PAGE_SIZE) + RW_DATA_SECTION(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE) + _edata = .; + + EXCEPTION_TABLE(16) + NOTES + BSS_SECTION(4, 4, 4) + _end = .; + + STABS_DEBUG + DWARF_DEBUG + + DISCARDS +} diff --git a/arch/nds32/mm/Makefile b/arch/nds32/mm/Makefile new file mode 100644 index 0000000..278d28f --- /dev/null +++ b/arch/nds32/mm/Makefile @@ -0,0 +1,7 @@ +obj-y := extable.o tlb.o \ + fault.o init.o ioremap.o mmap.o \ + mm-nds32.o cacheflush.o proc-n13.o + +obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o +obj-$(CONFIG_HIGHMEM) += highmem.o +CFLAGS_proc-n13.o += -fomit-frame-pointer