Received: by 10.223.164.202 with SMTP id h10csp602080wrb; Wed, 8 Nov 2017 23:50:19 -0800 (PST) X-Google-Smtp-Source: ABhQp+R8GsJx66bJHMKt9pqXmVNLqfzjNnCPhMFfvBZaazQ/3Blnui1oSeQGE2SOigknx6jOJ15h X-Received: by 10.84.214.9 with SMTP id h9mr2905717pli.261.1510213819109; Wed, 08 Nov 2017 23:50:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510213819; cv=none; d=google.com; s=arc-20160816; b=rJYGCw2Tk5kv6Tix1H1Ua9wtJym7k8V+QPvW9Fxym52uhRqQpTI5KaJkYbA5PWQVyu 7ESfyfuquvxBuiD4EwEp21okteMrVxZs7iUjZ2/OcQNpD/GIwz4s+ZVdGwIpqhgM6n23 WDxOCGsknjLAESEhsipw2PfPoQSMJZIawHNJgXuCFsJ0ILjovc9XXgP/atL5idqek8R1 3mSeVz0VJ10IN59l1kFX49kGkyp1Za9dEE/66UJBzwb0gEdqbF6w4qNiDA/V+uGnP2ZD IaiAL85wcOAWyHlJBatlgs+jIe1bfMpcr+juuVNNcQ3Q/j3X+2w3w1dLNHR+2pgp94me TiMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=mxdEK28//lmrM8238X+HltRKRBqPA2aCcqaBZjLmtl4=; b=S9tirZQAEhUdfO9xX7fDFefUX10LMWpeu0vsrazqBb9EM/2knMLz5lqAi8H9OWdSsF /QAak3rFSL8XI3G8/hr4lFLPOafunzwzShTu9S+0X8flpnPQM0pn8CaEgZ1jTepVeKeg KNHS9+MVkzQ14SitTPOGzIuZduHvPILdrAP2pT8xQagODwff5nPcJGWsjybZ+mZq7eMV qpNb88Z0/QIb9Ux8Lr06PvvLBoWgEPXl+OZ3xDIPo41DGe5lrf5QJq1rNCgyH5sZgwIP rwsvFQMjzjmr3ApN/UwcqCOQTXuXmQ8KckLNIT1+AQamweUIjY1YU3jpDO6nG53JpInu SaMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Avxh6a9U; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o9si5508212pge.179.2017.11.08.23.50.07; Wed, 08 Nov 2017 23:50:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Avxh6a9U; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752923AbdKIHtY (ORCPT + 82 others); Thu, 9 Nov 2017 02:49:24 -0500 Received: from mail-ua0-f196.google.com ([209.85.217.196]:54283 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752876AbdKIHtV (ORCPT ); Thu, 9 Nov 2017 02:49:21 -0500 Received: by mail-ua0-f196.google.com with SMTP id j14so3757641uag.11; Wed, 08 Nov 2017 23:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mxdEK28//lmrM8238X+HltRKRBqPA2aCcqaBZjLmtl4=; b=Avxh6a9U432Iacu5kNlXZuAzVVFJbQPRiuwfgiv/HPUNPDa199dq91vmDl7kpN03aR RuNyqWBGMQg/mooN9C7FYL9Du8LxbcSptp8c0TE7fZktYobwQHmO2/IcKbsid38F3yE8 HZ8NRrkoHSYEPhJpJLKyqAoABWON7wtfcAAZKDTxVr8S8mIXWO0TvHaK5wVErn/idcye jhZOKtm7IuWp4++Vimo5wazcR95WpLV+b0cAEtEPkzg+7G3II1SY+D9LfvbBdO7PsnAM jVQ9Cu5MQRsc021bD1rQI5CfjphTtDclZccy3HhamZq4ykFGvBZoX7k1oSEBxAUXtUdg FNKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mxdEK28//lmrM8238X+HltRKRBqPA2aCcqaBZjLmtl4=; b=OChKuw+tWhTUlM5Bq852aTv0UfXlUDxwnN8MZwH/XFvfThBC9YUz7hoD6Wv6Y5jLrQ z4De3PIuFA6KT1ce1B/7tWvYIShRkpaLjXhNIRcJnlW3lcjggN6Rcnxm28cltfNcu9Bx /Ut8zGMa/c5dgH5K1kkoLF+hl6c9QmZJ8GO6n7MhYbAfxaIUy0tYGj3Y7rqsUl6+z+0C Ji8jH6keWwFp05iH8zcoeb/GK0vyMBZyoDRUQV5OwU5jsKcW+ofWCrDv5jxVmxJWrEFe ouPC4VdrV+/dHnqiHtAJTBbU5W113nlnUTX5X07R0rgIiAswevG17eZ90BVYDg5HbtKP /flQ== X-Gm-Message-State: AJaThX5W0Ic3sDJlkf2uRbHRWE2uRn8pUxQygHYj2eiUcOQSxs5hb6b/ UEb/4PSxmLc3j2Vy5QMmS2prkGijKXkA1Vu4A50= X-Received: by 10.176.21.174 with SMTP id i43mr2607802uae.142.1510213760645; Wed, 08 Nov 2017 23:49:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.62.8 with HTTP; Wed, 8 Nov 2017 23:48:40 -0800 (PST) In-Reply-To: References: From: Greentime Hu Date: Thu, 9 Nov 2017 15:48:40 +0800 Message-ID: Subject: Re: [PATCH 23/31] nds32: Device tree support To: Arnd Bergmann Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-11-08 17:53 GMT+08:00 Arnd Bergmann : > On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu wrote: >> From: Greentime Hu >> >> Signed-off-by: Vincent Chen >> Signed-off-by: Greentime Hu >> --- >> arch/nds32/boot/dts/Makefile | 8 ++++++ >> arch/nds32/boot/dts/ae3xx.dts | 55 ++++++++++++++++++++++++++++++++++++ >> arch/nds32/boot/dts/ag101p.dts | 60 ++++++++++++++++++++++++++++++++++++++++ >> arch/nds32/kernel/devtree.c | 45 ++++++++++++++++++++++++++++++ >> 4 files changed, 168 insertions(+) >> create mode 100644 arch/nds32/boot/dts/Makefile >> create mode 100644 arch/nds32/boot/dts/ae3xx.dts >> create mode 100644 arch/nds32/boot/dts/ag101p.dts >> create mode 100644 arch/nds32/kernel/devtree.c >> >> diff --git a/arch/nds32/boot/dts/Makefile b/arch/nds32/boot/dts/Makefile >> new file mode 100644 >> index 0000000..d31faa8 >> --- /dev/null >> +++ b/arch/nds32/boot/dts/Makefile >> @@ -0,0 +1,8 @@ >> +ifneq '$(CONFIG_NDS32_BUILTIN_DTB)' '""' >> +BUILTIN_DTB := $(patsubst "%",%,$(CONFIG_NDS32_BUILTIN_DTB)).dtb.o >> +else >> +BUILTIN_DTB := >> +endif >> +obj-$(CONFIG_OF) += $(BUILTIN_DTB) > > For new architectures, I think it's better to not support built-in dtb > but instead require the > boot loader to be aware of device trees. Thanks. I got your point and we have uboot supporting DTB too. But we use gdb to load vmlinux without uboot sometimes, it can help us to verify kernel more easily. If dtb pointer is set by uboot, we will use it instead of using built-in dtb. >> +clean-files := *.dtb *.dtb.S >> diff --git a/arch/nds32/boot/dts/ae3xx.dts b/arch/nds32/boot/dts/ae3xx.dts >> new file mode 100644 >> index 0000000..b6c85dc >> --- /dev/null >> +++ b/arch/nds32/boot/dts/ae3xx.dts >> @@ -0,0 +1,55 @@ >> +/dts-v1/; >> +/ { >> + compatible = "nds32 ae3xx"; > > ae3xx looks like a wildcard name for multiple boards. Please always > have compatible > names without wildcards. You usually also want to list both the SoC > and the board > here. Thanks. It looks a little bit weird but its not a wildcards. :p I will list all the names instead of wildcards if I need to add more platforms. >> + #address-cells = <1>; >> + #size-cells = <1>; >> + interrupt-parent = <&intc>; >> + >> + chosen { >> + bootargs = "console=ttyS0,38400n8 earlyprintk=uart8250-32bit,0xf0300000 debug loglevel=7"; >> + }; > > Remove the earlyprintk option from the bootargs here, regular boards > should never rely > on earlyprintk. The "earlycon" support in the uart drivers works > almost as well (it starts > slightly later in the boot process), and it will pick up the uart from > the chosen/stdout-path > property. Thanks. I will remove it. >> + if (!params || !early_init_dt_scan(params)) { >> + pr_crit("\n" >> + "Error: invalid device tree blob at (virtual address 0x%p)\n" >> + "The dtb must be 8-byte aligned and must not exceed 8 KB in size\n" >> + "\nPlease check your bootloader.", params); > > What is the 8KB limit for the dtb for? This sounds really limiting > once you get to > more complex SoCs. Thanks. We allow uboot to set its start address and we think it might not be too big thus we limit it to 8KB. Maybe I should use a big size for complex SoCs. I will update it in the next version patch. From 1583491175897793613@xxx Wed Nov 08 09:54:24 +0000 2017 X-GM-THRID: 1583483396163909060 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread