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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8BD64C433EF for ; Thu, 10 Feb 2022 19:20:37 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 26AAE83055; Thu, 10 Feb 2022 20:20:35 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com 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; unprotected) header.d=gmail.com header.i=@gmail.com header.b="YLC6GcTy"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 479F283055; Thu, 10 Feb 2022 20:20:33 +0100 (CET) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 3C37D82F5A for ; Thu, 10 Feb 2022 20:20:29 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mr.bossman075@gmail.com Received: by mail-qk1-x72a.google.com with SMTP id 71so5915258qkf.4 for ; Thu, 10 Feb 2022 11:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=bHv7658PyEjIZHPbP+FiG0kkCkz2k3E7dDsufw6zV5Q=; b=YLC6GcTycC2+2/4IteHSK2nUA1e9EhN2AoRO0dR8Yu1DjlX3PG6GvsN5WtDbs1ueAe afNmcL2cKkhiahyUW4eL6QrWFhA9HZLUesX0nBkMebhrSwuNJb6zMAV15Mc5beJlx+TF fDGKYrGNG446s6tWOuDseBU4Ai638V07MjXF99n0Vg0JLqIbwsaZNd1E3nKbAt1/Nmab wsxbA89/uVL7uHlNkj9Y3tLR0oNWLbgkzLYKFrXi9Bxh6O2A7jPy+3DFJECAswLyIU0o zs7JHlXcJ9CXHhNQPe93EcSha8eY1CRMNOgIqZSFUHR3oBBW8FfbHbVoyZfJv68P4R8l fjvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=bHv7658PyEjIZHPbP+FiG0kkCkz2k3E7dDsufw6zV5Q=; b=Z/bH3WhWUwxVuTzyl6FQlnxA+FTBEqkepNnAP56tYiR+9jxAYw467NA6hSmgy2WBvs Qk7faT7PGl8Nx+UEpk/hs0xe10hzwZ2O1yFUrzSosdn2GyR2TWgAcR4aG8+4ru9osjAk c8jSNZDmoch/s2kepcr4oZ8+d8ea1vwfeJBmKrXs3I/rip8t9Qp/DJz+UlqAThkedJG2 BZrYalMvDDM6t/oAGG7KXMj9PCtc5YFWr9WgCcqxz1vrwvfQnxRcwQEQssQ69kH/rCZ9 RcG+E2DVlqQYAdqqWT3/DbKZ3RoPxFdL3DtphvBD/vhANQjrFhEPZL7wBtRjHk3JKgmN JVaA== X-Gm-Message-State: AOAM533wR7+hXCaxUIkXzOVdGlawLBhE9Dc+GZHeY3IkHB6IdTTmPbV2 is00j2jwoZwEaT6AezNsdxw= X-Google-Smtp-Source: ABdhPJwewb96u+29Z8gTEFH/k0CDIg+dXK+sYnLkgxly6CPHRepuna4O2Y+9uMM7lPTiFJHNTNJRxQ== X-Received: by 2002:ae9:c00b:: with SMTP id u11mr4582186qkk.757.1644520828013; Thu, 10 Feb 2022 11:20:28 -0800 (PST) Received: from [10.4.10.38] (146-115-144-188.s4282.c3-0.nwt-cbr1.sbo-nwt.ma.cable.rcncustomer.com. [146.115.144.188]) by smtp.gmail.com with ESMTPSA id l13sm3992495qtx.32.2022.02.10.11.20.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Feb 2022 11:20:27 -0800 (PST) Message-ID: Date: Thu, 10 Feb 2022 14:20:26 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v1 1/3] mach-sunxi: Add boot device detection for SUNIV Content-Language: en-US To: Andre Przywara Cc: u-boot@lists.denx.de, jagan@amarulasolutions.com, hdegoede@redhat.com, sjg@chromium.org, icenowy@aosc.io, marek.behun@nic.cz, festevam@denx.de, narmstrong@baylibre.com, tharvey@gateworks.com, christianshewitt@gmail.com, pbrobinson@gmail.com, jernej.skrabec@gmail.com, hs@denx.de, samuel@sholland.org, arnaud.ferraris@gmail.com, giulio.benetti@benettiengineering.com, thirtythreeforty@gmail.com References: <20220210043438.1706939-1-Mr.Bossman075@gmail.com> <20220210043438.1706939-2-Mr.Bossman075@gmail.com> <20220210105746.16f5004a@donnerap.cambridge.arm.com> From: Jesse Taube In-Reply-To: <20220210105746.16f5004a@donnerap.cambridge.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean On 2/10/22 05:57, Andre Przywara wrote: > On Wed, 9 Feb 2022 23:34:36 -0500 > Jesse Taube wrote: > > Hi Jesse, > > many thanks for sending this, much appreciated! > >> Use Samuel's suggestion of looking at the BootRom's stack >> to determine the boot device. > > Can you please elaborate here what's going on, for future reference? Like: > ============= > In contrast to other Allwinner SoCs the F1C100s BROM does not store a boot > source indicator in the eGON header in SRAM. This leaves us guessing where > we were exactly booted from, and for instance trying the SD card first, > even though we booted from SPI flash. > By inspecting the BROM code and by experimentation, Samuel found that the > top of the BROM stack contains unique pointers for each of the boot > sources, which we can use as a boot source indicator. > > Remove the existing board_boot_order kludge and replace it with a proper > boot source indication function. > ============= > > >> >> Signed-off-by: Jesse Taube >> Suggested-by: Samuel Holland >> --- >> arch/arm/include/asm/arch-sunxi/spl.h | 15 ++++++++ >> arch/arm/mach-sunxi/board.c | 50 ++++++++++++--------------- >> 2 files changed, 38 insertions(+), 27 deletions(-) >> >> diff --git a/arch/arm/include/asm/arch-sunxi/spl.h b/arch/arm/include/asm/arch-sunxi/spl.h >> index 58cdf806d9..d069091297 100644 >> --- a/arch/arm/include/asm/arch-sunxi/spl.h >> +++ b/arch/arm/include/asm/arch-sunxi/spl.h >> @@ -19,8 +19,23 @@ >> #define SUNXI_BOOTED_FROM_MMC0_HIGH 0x10 >> #define SUNXI_BOOTED_FROM_MMC2_HIGH 0x12 >> >> +/* >> + * Values taken from the Bootrom's stack used >> + * to determine where we booted from. >> + * 0xffff40f8: mmc0 >> + * 0xffff4114: spi0 NAND >> + * 0xffff4130: spi0 NOR >> + * 0xffff4150: mmc1 > > Those last four lines are redundant, as you say exactly that, in code, > down here again. Comments are good, speaking code is better. > >> + */ >> + >> +#define SUNIV_BOOTED_FROM_MMC0 0xffff40f8 >> +#define SUNIV_BOOTED_FROM_NAND 0xffff4114 >> +#define SUNIV_BOOTED_FROM_SPI 0xffff4130 >> +#define SUNIV_BOOTED_FROM_MMC1 0xffff4150 >> + >> #define is_boot0_magic(addr) (memcmp((void *)(addr), BOOT0_MAGIC, 8) == 0) >> >> uint32_t sunxi_get_boot_device(void); >> +uint32_t suniv_get_boot_device(void); >> >> #endif >> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c >> index 57078f7a7b..b0658d583e 100644 >> --- a/arch/arm/mach-sunxi/board.c >> +++ b/arch/arm/mach-sunxi/board.c >> @@ -241,6 +241,25 @@ uint32_t sunxi_get_boot_device(void) >> return -1; /* Never reached */ >> } >> >> +uint32_t suniv_get_boot_device(void) > > This can be static, right? > >> +{ >> + /* Get the last function call from BootRom's stack. */ >> + u32 brom_call = *(u32 *)(fel_stash.sp - 4);You are okay with this I was expecting you to explain a better way that i don't know about. >> + >> + switch (brom_call) { >> + case SUNIV_BOOTED_FROM_MMC0: >> + return BOOT_DEVICE_MMC1; >> + case SUNIV_BOOTED_FROM_NAND: >> + case SUNIV_BOOTED_FROM_SPI: >> + return BOOT_DEVICE_SPI; >> + case SUNIV_BOOTED_FROM_MMC1: >> + return BOOT_DEVICE_MMC2; >> + } > > Don't you need to handle FEL boot here somehow? Yes but I have no clue what the SP is also wouldn't we have it hang anyway. The other changes requested i have fixed, I'm sorry about the subpar commit descriptions. Thanks, Jesse > Cheers, > Andre > >> + >> + printf("Unknown boot source from BROM: 0x%x\n", brom_call); >> + return BOOT_DEVICE_MMC1; >> +} >> + >> #ifdef CONFIG_SPL_BUILD >> static u32 sunxi_get_spl_size(void) >> { >> @@ -276,36 +295,13 @@ unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc, >> return sector; >> } >> >> -#ifdef CONFIG_MACH_SUNIV >> -/* >> - * The suniv BROM does not pass the boot media type to SPL, so we try with the >> - * boot sequence in BROM: mmc0->spinor->fail. >> - * TODO: This has the slight chance of being wrong (invalid SPL signature, >> - * but valid U-Boot legacy image on the SD card), but this should be rare. >> - * It looks like we can deduce from some BROM state upon entering the SPL >> - * (registers, SP, or stack itself) where the BROM was coming from and use >> - * that here. >> - */ >> -void board_boot_order(u32 *spl_boot_list) >> -{ >> - /* >> - * See the comments above in sunxi_get_boot_device() for information >> - * about FEL boot. >> - */ >> - if (!is_boot0_magic(SPL_ADDR + 4)) { >> - spl_boot_list[0] = BOOT_DEVICE_BOARD; >> - return; >> - } >> - >> - spl_boot_list[0] = BOOT_DEVICE_MMC1; >> - spl_boot_list[1] = BOOT_DEVICE_SPI; >> -} >> -#else >> u32 spl_boot_device(void) >> { >> - return sunxi_get_boot_device(); >> + if (IS_ENABLED(CONFIG_MACH_SUNIV)) >> + return suniv_get_boot_device(); >> + else >> + return sunxi_get_boot_device(); >> } >> -#endif >> >> __weak void sunxi_sram_init(void) >> { >