From: Greentime Hu <green.hu@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greentime <greentime@andestech.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Marc Zyngier <marc.zyngier@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Networking <netdev@vger.kernel.org>,
Vincent Chen <vincentc@andestech.com>
Subject: Re: [PATCH 26/31] nds32: Build infrastructure
Date: Fri, 10 Nov 2017 16:26:58 +0800 [thread overview]
Message-ID: <CAEbi=3c7tduSHQ2HEAfcJF8A3QPD493_gHPK=_WiQGtSr0bc=A@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3i+_ZRcR9ab=Pf26R+1JKuzz3VKQxA=mL131KDCpobHA@mail.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.
>>>> +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.
next prev parent reply other threads:[~2017-11-10 8:27 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 5:54 [PATCH 00/31] Andes(nds32) Linux Kernel Port Greentime Hu
2017-11-08 5:54 ` [PATCH 01/31] nds32: Assembly macros and definitions Greentime Hu
2017-11-08 5:54 ` [PATCH 02/31] nds32: Kernel booting and initialization Greentime Hu
2017-11-08 13:38 ` Rob Herring
2017-11-09 9:49 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 03/31] nds32: Support early_printk Greentime Hu
2017-11-08 9:47 ` Tobias Klauser
2017-11-09 7:19 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 04/31] nds32: Exception handling Greentime Hu
2017-11-08 8:23 ` Arnd Bergmann
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B4974CE@ATCPCS16.andestech.com>
2017-11-13 10:54 ` Fwd: FW: " Vincent Chen
2017-11-08 5:54 ` [PATCH 05/31] nds32: MMU definitions Greentime Hu
2017-11-08 8:36 ` Arnd Bergmann
2017-11-08 8:46 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 06/31] nds32: MMU initialization Greentime Hu
2017-11-08 5:54 ` [PATCH 07/31] nds32: MMU fault handling and page table management Greentime Hu
2017-11-08 5:54 ` [PATCH 08/31] nds32: Cache and TLB routines Greentime Hu
2017-11-08 8:45 ` Arnd Bergmann
2017-11-08 9:01 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 09/31] nds32: Process management Greentime Hu
2017-11-08 5:54 ` [PATCH 10/31] nds32: IRQ handling Greentime Hu
2017-11-08 8:49 ` Arnd Bergmann
2017-11-08 9:06 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 11/31] nds32: Atomic operations Greentime Hu
2017-11-08 8:54 ` Arnd Bergmann
2017-11-08 9:32 ` vincentc
2017-11-20 14:29 ` Will Deacon
2017-11-22 3:02 ` Vincent Chen
2017-11-08 5:55 ` [PATCH 12/31] nds32: Device specific operations Greentime Hu
2017-11-08 9:04 ` Arnd Bergmann
2017-11-09 7:04 ` Greentime Hu
2017-11-10 16:07 ` Greentime Hu
2017-11-10 16:14 ` Arnd Bergmann
2017-11-22 10:02 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 13/31] nds32: DMA mapping API Greentime Hu
2017-11-08 9:09 ` Arnd Bergmann
2017-11-09 7:12 ` Greentime Hu
2017-11-09 10:14 ` Arnd Bergmann
2017-11-10 8:13 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 14/31] nds32: ELF definitions Greentime Hu
2017-11-08 5:55 ` [PATCH 15/31] nds32: System calls handling Greentime Hu
2017-11-08 9:30 ` Arnd Bergmann
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B497241@ATCPCS16.andestech.com>
2017-11-13 2:51 ` Fwd: FW: " Vincent Chen
2017-11-13 11:42 ` Arnd Bergmann
2017-11-22 3:13 ` Vincent Chen
2017-11-08 5:55 ` [PATCH 16/31] nds32: VDSO support Greentime Hu
2017-11-08 9:37 ` Arnd Bergmann
2017-11-08 20:00 ` Deepa Dinamani
2017-11-08 20:06 ` Arnd Bergmann
2017-11-08 20:14 ` Deepa Dinamani
2017-11-08 5:55 ` [PATCH 17/31] nds32: Signal handling support Greentime Hu
2017-11-09 1:26 ` Al Viro
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B497460@ATCPCS16.andestech.com>
2017-11-13 2:34 ` Fwd: FW: " Vincent Chen
2017-11-08 5:55 ` [PATCH 18/31] nds32: Library functions Greentime Hu
2017-11-08 9:45 ` Arnd Bergmann
2017-11-09 0:40 ` Al Viro
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B497559@ATCPCS16.andestech.com>
2017-11-14 4:47 ` Fwd: FW: " Vincent Chen
2017-11-18 2:44 ` Al Viro
2017-11-08 5:55 ` [PATCH 19/31] nds32: Debugging support Greentime Hu
2017-11-08 5:55 ` [PATCH 20/31] nds32: L2 cache support Greentime Hu
2017-11-08 9:48 ` Arnd Bergmann
2017-11-09 7:24 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 21/31] nds32: Loadable modules Greentime Hu
2017-11-08 5:55 ` [PATCH 22/31] nds32: Generic timers support Greentime Hu
2017-11-08 5:55 ` [PATCH 23/31] nds32: Device tree support Greentime Hu
2017-11-08 9:53 ` Arnd Bergmann
2017-11-09 7:48 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 24/31] nds32: Miscellaneous header files Greentime Hu
2017-11-08 9:57 ` Arnd Bergmann
2017-11-08 5:55 ` [PATCH 25/31] nds32: defconfig Greentime Hu
2017-11-08 10:03 ` Arnd Bergmann
2017-11-09 8:00 ` Greentime Hu
2017-11-09 10:20 ` Arnd Bergmann
2017-11-10 8:16 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 26/31] nds32: Build infrastructure Greentime Hu
2017-11-08 10:16 ` Arnd Bergmann
2017-11-09 9:02 ` Greentime Hu
2017-11-09 10:33 ` Arnd Bergmann
2017-11-10 8:26 ` Greentime Hu [this message]
2017-11-17 12:39 ` Greentime Hu
2017-11-17 12:50 ` Arnd Bergmann
2017-11-17 13:50 ` Greentime Hu
2017-11-13 10:45 ` Geert Uytterhoeven
2017-11-16 10:03 ` Greentime Hu
2017-11-16 10:25 ` Arnd Bergmann
2017-11-17 13:53 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 27/31] dt-bindings: interrupt-controller: Andestech Internal Vector Interrupt Controller Greentime Hu
2017-11-08 13:25 ` Rob Herring
2017-11-09 9:43 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 28/31] irqchip: Andestech Internal Vector Interrupt Controller driver Greentime Hu
2017-11-08 14:24 ` Marc Zyngier
2017-11-09 10:10 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 29/31] MAINTAINERS: Add nds32 Greentime Hu
2017-11-08 13:31 ` Rob Herring
2017-11-09 9:46 ` Greentime Hu
2017-11-09 10:36 ` Arnd Bergmann
2017-11-14 15:39 ` Joe Perches
2017-11-16 12:22 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 30/31] dt-bindings: nds32 CPU Bindings Greentime Hu
2017-11-08 13:18 ` Rob Herring
2017-11-09 9:39 ` Greentime Hu
2017-11-09 13:57 ` Rob Herring
2017-11-10 6:22 ` Greentime Hu
2017-11-10 8:25 ` Arnd Bergmann
2017-11-10 8:43 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 31/31] net: faraday add nds32 support Greentime Hu
2017-11-08 8:32 ` [PATCH 00/31] Andes(nds32) Linux Kernel Port David Howells
2017-11-08 8:41 ` Greentime Hu
2017-11-08 10:18 ` Arnd Bergmann
2017-11-09 9:26 ` Greentime Hu
2017-11-08 10:26 ` Arnd Bergmann
2017-11-09 9:33 ` Greentime Hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEbi=3c7tduSHQ2HEAfcJF8A3QPD493_gHPK=_WiQGtSr0bc=A@mail.gmail.com' \
--to=green.hu@gmail.com \
--cc=arnd@arndb.de \
--cc=greentime@andestech.com \
--cc=jason@lakedaemon.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincentc@andestech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).