[PATCH v2] ARM: dts: ixp4xx: Add Arcom Vulcan device tree
Marc Zyngier
maz at kernel.org
Tue Jul 27 11:44:31 PDT 2021
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 <linus.walleij at linaro.org> wrote:
>
> This adds a device tree for the Arcom Vulcan IXP42x board.
>
> Cc: Marc Zyngier <maz at kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> 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 <dt-bindings/input/input.h>
> +
> +/ {
> + model = "Arcom/Eurotech Vulcan";
> + compatible = "arcom,vulcan", "intel,ixp42x";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + memory at 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 at c4000000 {
> + flash at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 0 {
> + reg = <0>;
> + };
> +
> + phy1: ethernet-phy at 1 {
> + reg = <1>;
> + };
> + };
> + };
> +
> + /* EthC */
> + ethernet at 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.
More information about the linux-arm-kernel
mailing list