From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5925CC4338F for ; Tue, 27 Jul 2021 18:52:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1E9C560FC2 for ; Tue, 27 Jul 2021 18:52:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1E9C560FC2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WK2gZNxI42Q1bi7L1y6uDBl1wqfVRIz+e4G2lMjsTnU=; b=xeIagRafgbNdXM CczQed/rJnaFdNDMn+h0zFutwjL+T8rQ2MrrtrXrkVdao1ZsxdcwuStA+/02q8n5uW3juQarN+iY6 OwTZHqwOpIFUnAty9SpZXbUc8VVRNXVpI5JFrCIFT/Y/Nz7zT2WrOiVDkhCX0fmjJsL2ljyX3w7BF pgVQgx4NYJgTPIYrYwPjVhuUbEnESJ3G7/F5JEOfiak8buvGcEtd81khVBn9q9vu7azBC/trK5mCf VGVsdROsaczNZ10cPHy4vkozYfAP77JQFMuLvvE+cVJpze22V3QGnWDJz/yltY1UQRY8stZtSTFOV HBj7TBxl7ltHZGgoeXcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8S9f-00G15x-7m; Tue, 27 Jul 2021 18:50:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8S4A-00Fyrz-Ln for linux-arm-kernel@lists.infradead.org; Tue, 27 Jul 2021 18:44:36 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3198560E09; Tue, 27 Jul 2021 18:44:34 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m8S48-001NIn-6a; Tue, 27 Jul 2021 19:44:32 +0100 Date: Tue, 27 Jul 2021 19:44:31 +0100 Message-ID: <87bl6negvk.wl-maz@kernel.org> From: Marc Zyngier To: Linus Walleij Cc: linux-arm-kernel@lists.infradead.org, Imre Kaloz , Krzysztof Halasa Subject: Re: [PATCH v2] ARM: dts: ixp4xx: Add Arcom Vulcan device tree In-Reply-To: <20210726122458.2579760-1-linus.walleij@linaro.org> References: <20210726122458.2579760-1-linus.walleij@linaro.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: linus.walleij@linaro.org, linux-arm-kernel@lists.infradead.org, kaloz@openwrt.org, khalasa@piap.pl X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210727_114434_823093_21D3985C X-CRM114-Status: GOOD ( 42.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Linus, Thanks a lot for doing this. I'm slowly getting this box up and running again, and noticed a couple of issues with the DT, see below. On Mon, 26 Jul 2021 13:24:58 +0100, Linus Walleij wrote: > > This adds a device tree for the Arcom Vulcan IXP42x board. > > Cc: Marc Zyngier > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Fix up phy reg to 0 for phy0 > - Adjust to altered expansion bus bindings. > --- > arch/arm/boot/dts/Makefile | 3 +- > .../boot/dts/intel-ixp42x-arcom-vulcan.dts | 167 ++++++++++++++++++ > 2 files changed, 169 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/intel-ixp42x-arcom-vulcan.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 5500eac49eae..5618fae949db 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -248,7 +248,8 @@ dtb-$(CONFIG_ARCH_IXP4XX) += \ > intel-ixp42x-omicron-devixp.dtb \ > intel-ixp42x-omicron-miccpt.dtb \ > intel-ixp42x-omicron-mic256.dtb \ > - intel-ixp42x-netgear-wg302v2.dtb > + intel-ixp42x-netgear-wg302v2.dtb \ > + intel-ixp42x-arcom-vulcan.dtb > dtb-$(CONFIG_ARCH_KEYSTONE) += \ > keystone-k2hk-evm.dtb \ > keystone-k2l-evm.dtb \ > diff --git a/arch/arm/boot/dts/intel-ixp42x-arcom-vulcan.dts b/arch/arm/boot/dts/intel-ixp42x-arcom-vulcan.dts > new file mode 100644 > index 000000000000..16806deab559 > --- /dev/null > +++ b/arch/arm/boot/dts/intel-ixp42x-arcom-vulcan.dts > @@ -0,0 +1,167 @@ > +// SPDX-License-Identifier: ISC > +/* > + * Device Tree file for the Arcom/Eurotech Vulcan board. > + * This board is a single board computer in the PC/104 form factor based on > + * IXP425, and was released around 2005. It previously had the name "Mercury". > + */ > + > +/dts-v1/; > + > +#include "intel-ixp42x.dtsi" > +#include > + > +/ { > + model = "Arcom/Eurotech Vulcan"; > + compatible = "arcom,vulcan", "intel,ixp42x"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + memory@0 { > + /* CHECKME: 64 MB SDRAM - based on dma zone in boardfile */ Yup, that's standard. > + device_type = "memory"; > + reg = <0x00000000 0x4000000>; > + }; > + > + chosen { > + /* CHECKME: using a harddrive at /dev/sda1 as rootfs by default */ > + bootargs = "console=ttyS0,115200n8 root=/dev/sda1 rw rootfstype=ext4 rootwait"; I'd like not to hardcode a command line in the DT, but on the other hand passing a command-line can be... difficult if you are running a LE kernel. > + stdout-path = "uart0:115200n8"; > + }; > + > + aliases { > + serial0 = &uart0; > + }; > + > + onewire { > + compatible = "w1-gpio"; > + gpios = <&gpio0 14 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; > + }; > + > + soc { > + bus@c4000000 { > + flash@0,0 { > + compatible = "intel,ixp4xx-flash", "cfi-flash"; > + bank-width = <2>; > + /* > + * 32 MB of Flash in 0x20000 byte blocks > + * mapped in at CS0 and CS1 > + */ There is also a version with only 16MB. Now idea how to support this, and nobody yelled at me so far... ;-) > + reg = <0 0x00000000 0x2000000>; > + > + /* Expansion bus settings */ > + intel,ixp4xx-eb-t3 = <3>; > + intel,ixp4xx-eb-byte-access-on-halfword = <1>; > + intel,ixp4xx-eb-write-enable = <1>; > + > + partitions { > + compatible = "redboot-fis"; > + /* CHECKME: FIS eraseblock at 0x1fe0000? */ > + fis-index-block = <0xff>; This should be 0x1ff. > + }; > + }; > + sram@2,0 { > + /* 256 KB SDRAM memory at CS2 */ > + compatible = "shared-dma-pool"; Any reason why we can't use mtd-ram instead, like this was done in the board file? > + device_type = "memory"; > + reg = <1 0x00000000 0x40000>; This really should be CS2, not CS1. It otherwise clashes with the NOR flash and results in some interesting fireworks. > + no-map; > + /* Expansion bus settings */ > + intel,ixp4xx-eb-t3 = <1>; > + intel,ixp4xx-eb-t4 = <2>; > + intel,ixp4xx-eb-ahb-split-transfers = <1>; > + intel,ixp4xx-eb-write-enable = <1>; > + intel,ixp4xx-eb-byte-access = <1>; > + }; > + serial@3,0 { > + /* > + * 8250-compatible Exar XR16L2551 2 x UART > + * > + * CHECKME: if special tweaks are needed, then fix the > + * operating system to handle it. > + */ > + compatible = "exar,xr16l2551", "ns8250"; This fails to probe, but I haven't investigated it yet. > + reg = <3 0x00000000 0x10>; > + interrupt-parent = <&gpio0>; > + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; > + clock-frequency = <1843200>; > + /* Expansion bus settings */ > + intel,ixp4xx-eb-t3 = <3>; > + intel,ixp4xx-eb-cycle-type = <1>; /* Motorola cycles */ > + intel,ixp4xx-eb-write-enable = <1>; > + intel,ixp4xx-eb-byte-access = <1>; > + }; > + gpio1: gpio@4,0 { > + /* > + * MMIO GPIO in one byte > + */ > + compatible = "arcom,vulcan-gpio"; > + reg = <4 0x00000000 0x1>; > + /* Expansion bus settings */ > + intel,ixp4xx-eb-write-enable = <1>; > + intel,ixp4xx-eb-byte-access = <1>; > + }; > + watchdog@5,0 { > + compatible = "maxim,max6369"; > + reg = <5 0x00000000 0x1>; > + /* Expansion bus settings */ > + intel,ixp4xx-eb-write-enable = <1>; > + intel,ixp4xx-eb-byte-access = <1>; > + }; > + }; > + > + pci@c0000000 { > + status = "ok"; > + > + /* > + * Taken from Vulcan PCI boardfile. > + * > + * We have 2 slots (IDSEL) 1 and 2 with one dedicated interrupt > + * per slot. This interrupt is shared (OR:ed) by all four pins. > + * > + * CHECKME: is the interrupt setup on Vulcan really this cheap? Yeah, it is terrible. But on the other hand, there is no PCI slot, and all the devices (USB and CardBus) are directly integrated on the board. > + */ > + interrupt-map = > + /* IDSEL 1 */ > + <0x0800 0 0 1 &gpio0 2 3>, /* INT A on slot 1 is irq 2 */ > + <0x0800 0 0 2 &gpio0 2 3>, /* INT B on slot 1 is irq 2 */ > + <0x0800 0 0 3 &gpio0 2 3>, /* INT C on slot 1 is irq 2 */ > + <0x0800 0 0 4 &gpio0 2 3>, /* INT D on slot 1 is irq 2 */ > + /* IDSEL 2 */ > + <0x1000 0 0 1 &gpio0 3 3>, /* INT A on slot 2 is irq 3 */ > + <0x1000 0 0 2 &gpio0 3 3>, /* INT B on slot 2 is irq 3 */ > + <0x1000 0 0 3 &gpio0 3 3>, /* INT C on slot 2 is irq 3 */ > + <0x1000 0 0 4 &gpio0 3 3>; /* INT D on slot 2 is irq 3 */ All the intspecs should describe a LEVEL_LOW interrupt. What you have here isn't even legal... ;-) The CardBus bridge gets properly detected if I reduce the memory size to 8MB (as it was done in the board file), but somehow the CF card that's attached to it doesn't work. USB, on the other hand, seems to work fine. > + }; > + > + /* EthB */ > + ethernet@c8009000 { > + status = "ok"; > + queue-rx = <&qmgr 3>; > + queue-txready = <&qmgr 20>; > + phy-mode = "rgmii"; > + phy-handle = <&phy0>; > + > + mdio { > + #address-cells = <1>; > + #size-cells = <0>; > + > + phy0: ethernet-phy@0 { > + reg = <0>; > + }; > + > + phy1: ethernet-phy@1 { > + reg = <1>; > + }; > + }; > + }; > + > + /* EthC */ > + ethernet@c800a000 { > + status = "ok"; > + queue-rx = <&qmgr 4>; > + queue-txready = <&qmgr 21>; > + phy-mode = "rgmii"; > + phy-handle = <&phy1>; > + }; > + }; > +}; Somehow, my vintage kernel was able to get the MAC addresses, but I can't remember how. Yet. I'll try to find some time to debug the couple of nagging issues during the weekend, but it already works surprisingly well! Thanks again, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel