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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 6C124C433EF for ; Fri, 10 Sep 2021 06:19:59 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B70B6611AF for ; Fri, 10 Sep 2021 06:19:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B70B6611AF Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=northern.tech Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A18A1835CF; Fri, 10 Sep 2021 08:19:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=northern.tech Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; secure) header.d=northern.tech header.i=@northern.tech header.b="KX+QnS9O"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9FB1F83261; Fri, 10 Sep 2021 08:19:42 +0200 (CEST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A9C9B8020E for ; Fri, 10 Sep 2021 08:19:37 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=northern.tech Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=kristian.amlie@northern.tech Received: by mail-lj1-x231.google.com with SMTP id r3so1487834ljc.4 for ; Thu, 09 Sep 2021 23:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=northern.tech; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=vc0IIgyWpLEucJXpnwjwTEu2FaccQTVHcIT5azdI+VU=; b=KX+QnS9OBeFIUpgfKuSAiSIUzOeZbT50J0bbMm45F6TlmkhDt8vqbgXfNlFM0ppb0Z bugnDqYs2gRRCic1XhLDuG/QvWP7sRkI5/yhVyavXxWp5qWEWcJtOD+7TZwAt3WUhMfP u22sR9tAIqyrzqtB8hH0jIQbltZ9IYcW1PR3FeXau/6pKumeqOraG6C0ZoYKWs+PjnyY iuyleYljbmT9vPvYncHjeNNrVGGGLw/9pndpmz5R5ZSbbOiG7idusnbvYmYS/sFVh409 AqWDxJZIA/U5gs5XORjIkQvny/lcLz7A1cdNi9mbBPdISVKqP5smvTbxpyhUSAWsvNSV Zaag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=vc0IIgyWpLEucJXpnwjwTEu2FaccQTVHcIT5azdI+VU=; b=2GwunmXr0HS64kNRUS0vSBu1tK1FNCIfHBOX5mGDH3eF56R9eykKY1p20gBvN53SxU Uzagxmo5GC4KBaQO8jFlKBmDmvOTkcUyGMnRFimF8KXuxhl5TEflhH3RZF3xfpzjh2ja MB/v//OyVif7j13SUjl9HjVR8MfgqcCtnDyqXSmKJ18Lvswzcahw/AcwDJpFrZPAce3X ub3LrA5kH9lIT5qKSArfyHOpe1JpMQBgYUiLVV8RVbCuCfUcSdZCwoSkhfpAmzS8Zhf2 2r+WlvYX7YOxF3a3UkbHt6oTXu2KWtIhQ6eZ3f2kBcrH0RNO1bc5Ora9qG5+P4v1w0ur Gxvw== X-Gm-Message-State: AOAM531ftG1EYg6ONG2Aa2YE1oYa1OvpnPFs6Be4+tDzpL0Ks8I33t8o kXOZ7D2rj/nSWAM4jVfddLH3yg== X-Google-Smtp-Source: ABdhPJzfzc/Ye7BFWdhzBMsFu59JizZC6dCipny7KKstQ/UX+bt1kjPpBIcvH0pinCGASDzhGYmnpg== X-Received: by 2002:a2e:a4ca:: with SMTP id p10mr2867873ljm.415.1631254776791; Thu, 09 Sep 2021 23:19:36 -0700 (PDT) Received: from kristian-Mender-T460s.mender.io (195-159-235-214.customer.powertech.no. [195.159.235.214]) by smtp.googlemail.com with ESMTPSA id u24sm446329ljg.64.2021.09.09.23.19.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Sep 2021 23:19:36 -0700 (PDT) From: Kristian Amlie To: Tom Rini Cc: u-boot@lists.denx.de, Liviu Dudau Subject: Re: [PATCH 1/1] ARM: vexpress_ca9x4: Reintroduce board in order to use with QEMU. Date: Fri, 10 Sep 2021 08:19:18 +0200 Message-Id: <20210910061919.522-1-kristian.amlie@northern.tech> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210908135744.GD12964@bill-the-cat> References: <20210908135744.GD12964@bill-the-cat> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 08/09/2021 15:57, Tom Rini wrote: > On Tue, Sep 07, 2021 at 08:37:51AM +0200, Kristian Amlie wrote: > >> vexpress_ca9x4 is seemingly the only board except for qemu_arm which >> is able to run U-Boot correctly, using the `-M vexpress-a9` option to >> QEMU. Building for qemu_arm and running qemu-system-arm with the `-M >> virt` argument has a number of downsides, most importantly that it >> only supports virtio storage drivers. This significantly reduces its >> usefulness in testing memory card and Flash solutions, especially when >> the tested images are from a third party source. >> >> So therefore we reintroduce the vexpress_ca9x4 board in this commit, >> with the explicit goal of using it with QEMU. >> >> A number of differences to note from the original: >> >> * Since the board was apparently unmaintained, I have now set myself >> as the maintainer. >> >> * The board has been converted to use the driver model, which was the >> reason it was removed in the first place. >> >> * The vexpress_ca15_tc2 and vexpress_ca5x2 boards, which were removed >> in the same commit, are not necessary for the QEMU use case, and >> have been omitted. >> >> * An `mmc0` alias was introduced in the dts file. The mmc is not >> detected correctly without this, now that it's based on the device >> tree instead of the board's init function. >> >> * A couple of other nodes were removed because they were problematic >> when trying to run the UEFI bootmgr. Once again, the primary use >> case here is QEMU, and these nodes are not needed for that to work. >> >> * Unnecessary board init code has been removed, thanks to driver model >> and device tree. >> >> * `CONFIG_OF_EMBED` has been enabled. I know this goes against >> recommended practice, but there doesn't seem to be any other way to >> pass the dtb to U-Boot in the QEMU scenario. Using the -dtb argument >> does not work, I suppose because U-Boot doesn't use the same >> mechanics as the kernel when it's booting. > > This is something that should get looked at and figured out, but is > separate. I thought this did work on Pi for example. Yes, I tried messing with fdtaddr, but I couldn't get it to work without OF_EMBED. I don't know the implementation details well in this area, unfortunately. > >> * Load addresses have been changed to fit QEMU use case. >> >> People wanting to get a more detailed, yet somewhat isolated, diff >> between this and the original, can run this command: >> >> git diff c6c26a05b89f25a06e7562f8c2071b60fd0c9eac~1 -- \ >> $( git diff-tree --diff-filter=A -r --name-only HEAD~1 HEAD) >> >> (Make sure to either check out this commit first, or replace HEAD with >> the commit ID of this commit) >> >> Signed-off-by: Kristian Amlie > > I'm glad to see this come back. A request: > > [snip] >> diff --git a/include/configs/vexpress_ca9x4.h b/include/configs/vexpress_ca9x4.h >> new file mode 100644 >> index 0000000000..8157a5868d >> --- /dev/null >> +++ b/include/configs/vexpress_ca9x4.h >> @@ -0,0 +1,16 @@ >> +/* SPDX-License-Identifier: GPL-2.0+ */ >> +/* >> + * (C) Copyright 2011 Linaro >> + * Ryan Harkin, >> + * >> + * Configuration for Versatile Express. Parts were derived from other ARM >> + * configurations. >> + */ >> + >> +#ifndef __VEXPRESS_CA9X4_H >> +#define __VEXPRESS_CA9X4_H >> + >> +#define CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP >> +#include "vexpress_common.h" > > CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP looks to just be polluting the > CONFIG namespace, it's only then used.. > >> + >> +#endif /* VEXPRESS_CA9X4_H */ >> diff --git a/include/configs/vexpress_common.h b/include/configs/vexpress_common.h >> index b131480e5b..99a5dd064a 100644 >> --- a/include/configs/vexpress_common.h >> +++ b/include/configs/vexpress_common.h >> @@ -169,29 +169,10 @@ >> func(DHCP, dhcp, na) >> #include >> >> -#ifdef CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP >> -#define CONFIG_PLATFORM_ENV_SETTINGS \ >> - "loadaddr=0x80008000\0" \ >> - "ramdisk_addr_r=0x61000000\0" \ >> - "kernel_addr=0x44100000\0" \ >> - "ramdisk_addr=0x44800000\0" \ >> - "maxramdisk=0x1800000\0" \ >> - "pxefile_addr_r=0x88000000\0" \ >> - "scriptaddr=0x88000000\0" \ >> - "kernel_addr_r=0x80008000\0" >> -#elif defined(CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP) >> -#define CONFIG_PLATFORM_ENV_SETTINGS \ >> - "loadaddr=0xa0008000\0" \ >> - "ramdisk_addr_r=0x81000000\0" \ >> - "kernel_addr=0x0c100000\0" \ >> - "ramdisk_addr=0x0c800000\0" \ >> - "maxramdisk=0x1800000\0" \ >> - "pxefile_addr_r=0xa8000000\0" \ >> - "scriptaddr=0xa8000000\0" \ >> - "kernel_addr_r=0xa0008000\0" >> -#endif >> #define CONFIG_EXTRA_ENV_SETTINGS \ >> - CONFIG_PLATFORM_ENV_SETTINGS \ >> + "kernel_addr_r=0x60100000\0" \ >> + "fdt_addr_r=0x60000000\0" \ >> + "bootargs=console=tty0 console=ttyAMA0,38400n8\0" \ >> BOOTENV \ >> "console=ttyAMA0,38400n8\0" \ >> "dram=1024M\0" \ > > around here, to modify what the default environment is. Can you please > do a patch (a follow-up to this is fine) to rename it to just > VEXPRESS_ORIGINAL_MEMORY_MAP ? Thanks! Of course! Included in next patch. -- Kristian