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 E7216C433EF for ; Sat, 29 Jan 2022 21:23:29 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1CC6D82FA3; Sat, 29 Jan 2022 22:23:28 +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="gXSGScVR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2ACD3820FE; Sat, 29 Jan 2022 22:23:27 +0100 (CET) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 3B05A82FA3 for ; Sat, 29 Jan 2022 22:23:23 +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-qv1-xf32.google.com with SMTP id e20so9133901qvu.7 for ; Sat, 29 Jan 2022 13:23:23 -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=PLZKJ/wSsc5yxTqR3dclXH3ldJp9+m9EXiki9YstIJo=; b=gXSGScVR+UWLiX+wP8w7DzXPSi1vhTBb6ZKNT7Tg1n4R7SwkQqNuSIrrmkDpRSgcXU 0Cgdeiaf+9ziIam+eQG7npXX1rgjgQOQqZXihwtGNCwYSICGuOM/hAiIKRwR5oSM90fY +DEeiFbVBFFYoNMrbquFMN5yViBmTQz95AXFOutdPXhdfbBLXQMLAZHjx11KZfVZfH8y YA1STFQmSJKv1pkpyktDIwl0n5QMDDOvASm6gaxvruo7br6aUHZGoRy4J4JG28Zumdjc 5qR1JVCf8SfEY1ljYH7FW+IF62jUFn/pUrB/JnaVRqKVbm0P5F5IUS20D0FFpZRV+klo fRZA== 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=PLZKJ/wSsc5yxTqR3dclXH3ldJp9+m9EXiki9YstIJo=; b=gYUUI8FlwZNVJeUaY2ojuVu5Li3+Ba5kw0WGrgev0i5VzT5vq2t9Tn3ptAO+/012XI 4of2Wz+KfzkqmNzf4sPqetfoUGTGNOIuxNSCjutDS7JTzX5zWYLBDOkEQBFo0tJ5vuzb GWBigA0K6EfQK9D5tRqUQsiytcArtxdJH8PktqiXNEV+yO+pFjkjxfMHjXV3kmnCv40o In4yxsA8fuaQJnxUjrebKCn+FebTCXTYyQ5r/1JFAXFkUz6TDz01rSdWYVNS4cNESFKu NuRrnSIuDQCZgukC3XosvfSO27DXqQje6H1lP7ZPcMwhzegswI9eijEvBHmKiTlCVZsW eJjw== X-Gm-Message-State: AOAM533lt3ajYycWnQKYdh2bwh1bSrtI/XzJEyK4yoNalBJkgSpCPK+Q on3g3oAxctJwgtiebXCWD2k= X-Google-Smtp-Source: ABdhPJwfjK1hdQkJvyDy9p18iHjawBwm5ET0rOYXM5bapPGeDKeWy54LyrKPk6Nck+kP8KfrrOAudw== X-Received: by 2002:a05:6214:ca5:: with SMTP id s5mr11994273qvs.35.1643491402083; Sat, 29 Jan 2022 13:23:22 -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 v22sm5591200qta.60.2022.01.29.13.23.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Jan 2022 13:23:21 -0800 (PST) Message-ID: Date: Sat, 29 Jan 2022 16:23:20 -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 09/11] sunxi: Add support for SUNIV architecture Content-Language: en-US To: Giulio Benetti , Samuel Holland , 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, arnaud.ferraris@gmail.com, thirtythreeforty@gmail.com, Chris Morgan References: <20220105003508.1143140-1-Mr.Bossman075@gmail.com> <20220105003508.1143140-10-Mr.Bossman075@gmail.com> <20220126141321.32c9fb22@donnerap.cambridge.arm.com> <2d608b9d-b8f0-8d5b-2b6c-493e1461a6e8@gmail.com> <20220129115118.5a0022ef@slackpad.fritz.box> <9ee45f2e-b29f-5bd3-3007-125cdcaf501c@sholland.org> <070afd08-3d4d-15b1-f16d-24662fb0b273@gmail.com> <51e9bff7-9eba-75fb-1839-e5f8fa108159@benettiengineering.com> From: Jesse Taube In-Reply-To: <51e9bff7-9eba-75fb-1839-e5f8fa108159@benettiengineering.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 1/29/22 16:21, Giulio Benetti wrote: > On 29/01/22 22:19, Jesse Taube wrote: >> >> >> On 1/29/22 16:05, Jesse Taube wrote: >>> >>> >>> On 1/29/22 15:59, Samuel Holland wrote: >>>> On 1/29/22 5:51 AM, Andre Przywara wrote: >>>>> On Fri, 28 Jan 2022 22:21:28 -0500 >>>>> Jesse Taube wrote: >>>>>> On 1/26/22 09:38, Jesse Taube wrote: >>>>>>> On 1/26/22 09:13, Andre Przywara wrote: >>>>>>>> On Tue, 4 Jan 2022 19:35:06 -0500 >>>>>>>> Jesse Taube wrote: >>>>>>>> >>>>>>>>> u32 spl_boot_device(void) >>>>>>>>> { >>>>>>>>> return sunxi_get_boot_device(); >>>>>>>>> } >>>>>>>>> +#else >>>>>>>>> +/* >>>>>>>>> + * suniv BROM do not pass the boot media type to SPL, so we try with the >>>>>>>>> + * boot sequence in BROM: mmc0->spinor->fail. >>>>>>>>> + */ >>>>>>>>> +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; >>>>>>>> >>>>>>>> So does that mean that it tries MMC first, even when booted via SPI? So if >>>>>>>> there is a *non*-bootable microSD card in, it will read something from >>>>>>>> sector 80, and will execute that if this is a FIT or legacy image? >>>>>>> yes >>>>>> Uh sorry to bother you again but I cant seem to find a way to find where >>>>>> the bootrom got the spl. I could check other periphirals like pinmux. I >>>>>> could also just have it configured at build. Are both these options >>>>>> okay? I will try to find a way to find the boot device at runtime first. >>>>> >>>>> Don't bother for this version, it's fine as it is now, we can refine >>>>> this later. It's only a problem if there is a non-valid SPL, but a >>>>> valid U-Boot proper legacy image on the SD card. >>>>> I don't want to have a build time option, we try to keep a single image >>>>> for all boot sources. >>>>> So eventually I'd prefer the pinmux/clock check, since that's cheaper. >>>>> The alternative would be to read the SPL (again), check for a valid >>>>> header and verify the checksum. You can look at this for inspiration: >>>>> https://patchwork.ozlabs.org/project/uboot/patch/20210712100651.6912-3-andre.przywara@arm.com/ >>>> >>>> I checked the boot ROM code (thanks Jesse!), and indeed it does not report where >>>> it loaded SPL from, or make any other changes to the loaded eGON image. The boot >>>> ROM also completely cleans up its clock and pinctrl changes, regardless of the >>>> success/failure of a specific boot device. >>>> >>>> There's a function which loads some value to r2, but that gets called before the >>>> "load eGON from storage" functions, so r2 will be clobbered. >>>> >>>> So as far as I can tell, the only way to determine the boot device, other than >>>> reimplementing the BROM in SPL, is to look at the return address on the top of >>>> the BROM's stack. These are the possible values (in order of execution): >>>> >>>> 0xffff40f8: mmc0 >>>> 0xffff4114: spi0 NAND >>>> 0xffff4130: spi0 NOR >>>> 0xffff4150: mmc1 >>> >>> If i save it in save_boot_params it does change when in a different boot >>> device. Ill look into it more. >>> the sp is also a good idea. >> Sry Im just dumb. it does change but it is because it doesn't clean the >> registers. >> Thanks sam, looking at the stack is the best option. > > I've been too late :-) Im sorry only by a couple of seconds. > So happy assembly coding Jesse! Its very difficult :( I'm not used to how it works yet. Thanks, Jesse Taube > > Best regards