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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 301F7C11F67 for ; Wed, 30 Jun 2021 00:13:20 +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 5556C61D0B for ; Wed, 30 Jun 2021 00:13:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5556C61D0B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8020883202; Wed, 30 Jun 2021 02:13:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id B516683204; Wed, 30 Jun 2021 02:13:15 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 135D683200 for ; Wed, 30 Jun 2021 02:13:12 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0E0CED6E; Tue, 29 Jun 2021 17:13:11 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 254C03F5A1; Tue, 29 Jun 2021 17:13:10 -0700 (PDT) Date: Wed, 30 Jun 2021 01:12:44 +0100 From: Andre Przywara To: Tom Rini Cc: Simon Glass , u-boot@lists.denx.de, Linus Walleij , Liviu Dudau Subject: Re: [PATCH] arm: Add (back) VExpress boards support Message-ID: <20210630011244.09b55fbe@slackpad.fritz.box> In-Reply-To: <20210629180323.GA9516@bill-the-cat> References: <20210629114555.20805-1-andre.przywara@arm.com> <20210629121122.GV9516@bill-the-cat> <20210629151552.756ab8b2@slackpad.fritz.box> <20210629175210.1468b1e1@slackpad.fritz.box> <20210629180323.GA9516@bill-the-cat> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 29 Jun 2021 14:03:23 -0400 Tom Rini wrote: Hi Tom, > On Tue, Jun 29, 2021 at 05:52:10PM +0100, Andre Przywara wrote: > > On Tue, 29 Jun 2021 15:15:52 +0100 > > Andre Przywara wrote: > > > > Hi, > > > > > On Tue, 29 Jun 2021 08:11:22 -0400 > > > Tom Rini wrote: > > > > > > > On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote: > > > > > > > > > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile > > > > > Express platform, along with their CA5, CA9 and TC2 boards. The trigger > > > > > was the missing conversion of the MMC driver. > > > > > > > > > > Some folks complained about that internally, so bring those boards back, > > > > > but better than ever: > > > > > - Use DM and OF_CONTROL for all the boards. Use the .dts files from the > > > > > latest Linux kernel (5.13) for that. > > > > > - Move the board selection choice into the platform's Kconfig. > > > > > - Clean up some shared config and common definitions. > > > > > - Drop obsolete features like ATAGs support. > > > > > - Switch to the DM_ETH version of the SMC911X Ethernet driver. > > > > > - Drop MMC support. > > > > > > > > > > The PL180 MMC driver actually supports DM_MMC, but that requires a > > > > > DM_GPIO driver for the card detect GPIO, which we don't have. This > > > > > specific GPIO is actually handled via the "sysregs" device, so we would > > > > > need a driver for that. QEMU does not emulate this part, also the DT > > > > > description is somewhat "special", so this is left for later. > > > > > > > > > > This version compiles without any warning for all three boards now. > > > > > Tested on QEMU. > > > > > > > > > > Signed-off-by: Andre Przywara > > > > > --- > > > > > Hi, > > > > > > > > > > this relies on the SMC911x driver DT changes, as posted here: > > > > > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html > > > > > I put a version with the changes broken down here: > > > > > https://github.com/Andre-ARM/u-boot/commits/tc2-history > > > > > > > > > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with: > > > > > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G -smp 1 \ > > > > > -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \ > > > > > -device loader,file=u-boot.bin,addr=0x80800000 -nographic > > > > > > > > > > Where tramp-tc2.bin is a trampoline replacing the board's firmware: > > > > > 00000000 00 00 a0 e3 80 00 48 e3 10 ff 2f e1 > > > > > (mov r0, #0; movt r0, #0x8080; bx r0) > > > > > > > > > > The vexpress_ca9x4_defconfig uses a different memory map, so the runes are: > > > > > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \ > > > > > -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \ > > > > > -device loader,file=u-boot.bin,addr=0x60800000 -nographic > > > > > > > > > > tramp-ca9.bin: > > > > > 00000000 00 00 a0 e3 80 00 46 e3 10 ff 2f e1 > > > > > (mov r0, #0; movt r0, #0x6080; bx r0) > > > > > > > > My big question is how do we run this in CI? Or does it not _need_ that > > > > firmware file to really exist? Or is there a pending change to > > > > https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just > > > > have exist those magic empty bins? Thanks! > > > > > > So from digging into this I see that this loads U-Boot's ELF build, via > > > QEMU's -kernel parameter. Which is fine, but not really what is > > > happening on real hardware. > > > I checked and the v2021.04 version worked with this approach, but my > > > build does not. > > > I will have a look into this now. > > > > The new build uses OF_CONTROL and OF_SEPARATE, so the DTB gets appended > > to the U-Boot *image*. The ELF file is not treated this way, so the > > code reads only 0s after the end of the U-Boot code - which makes it > > die silently. Manually loading the DTB into DRAM would be fragile at > > best, but is also rejected by QEMU, because the LOAD program header > > extend for a few dozen bytes beyond U-Boot's "end" symbol, so it > > overlaps. > > Can't we pass the device tree to qemu (and in turn through to U-Boot) in > a clean and out of the box way? I thought there was a way to do that.. QEMU has a -dtb command, to take a DTB file, and puts that at the beginning of DRAM (if possible). Also we could load the DTB from the (emulated) NOR flash, like we do for the Juno board. But I think this is not the point: we don't really want this U-Boot port for the *QEMU* vexpress machine, but for the real hardware: and there is no DTB by default, not on the NOR flash, and certainly not in DRAM. The previous U-Boot port didn't need any DTBs at all, so we can't and shouldn't rely on any extra firmware provision. I think appending the DTBs to the U-Boot image is the right solution, so we get a self-contained U-Boot binary, acting as a drop-in replacement for the older port. Running under QEMU should just be a some easy way of CI testing, not a goal in itself. Hence I'd rather adapt the CI than the code. > > IIRC we don't have position independent code for ARM, so we can't load > > U-Boot into flash directly (which also would require some code changes > > first). > > Do you mean generate a file to use as the system flash and have U-Boot > be in the correct spot within that file? If so > bin/travis-ci/conf.qemu_mips_na in the test hooks repo might give you > some hints. Well yes, this was what I was thinking about, but just for the trampoline. The actual firmware loads U-Boot into DRAM, so we have to provide that load address in DRAM when building the image. If we were position independent (like arm64 is), we could cover both cases with one build, but this is not the case for ARM, IIUC. > > Anyway I don't think we should change any code to cope with that (by > > using another method to find the DTB), so adjusting the QEMU recipe > > sounds like a better idea. > > > > Is there a way to add those 12 byte trampoline files to the CI repo? Or > > shall they be created on the fly somehow? > > If we need to include the trampoline files, however it's easiest is > fine. So I can try to provide some recipe for travis-ci, based on what I see in the repo, but don't really know how to test this. I think I have a Travis-CI account, but would be glad about some hints or instructions how to test those u-boot-test-hooks bits easily. Cheers, Andre