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 819BFC74A5B for ; Sun, 19 Mar 2023 02:30:32 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A341685966; Sun, 19 Mar 2023 03:30:29 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (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=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DFLSToPI"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3670C859BC; Sun, 19 Mar 2023 03:30:26 +0100 (CET) Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) (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 DAE0883CB1 for ; Sun, 19 Mar 2023 03:30:19 +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=martin.p.rowe@gmail.com Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-177b78067ffso9761968fac.7 for ; Sat, 18 Mar 2023 19:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679193018; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1x1SBKU83zhYhqkLKQWuub45pFye7g6i2nlYwio45/k=; b=DFLSToPIBEA9MpU+4tWvOCyI2WUouwCQJ6kt6p2MsbqNemEndGfBAHmhI97uOGNYzK NKGXnYAazfV1fvyGsjPjHph2flNbPRcN00QLBZC+QdLje71CiQ3F2if7iZUUKmtSp3Xw nn+0agAflrUk8fPUcuAp0trNNLOdG+BVWCy2m9b0wh2n0Nbt5Cdh2AXjTv80o4iB2VFJ r1jRqaROgU6pONUsQFkqnvbt0VoF75bIy4OOKf7FY31c+Hd3zG8dr3Z4aZWL9ldQ/Gvt UP7Zxq8Osk5zHsC+hluxJ3oLUsuo4q2sCvOc7XpGlKQllX/tquwgGAC38xlX2t09wLjR s+3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679193018; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1x1SBKU83zhYhqkLKQWuub45pFye7g6i2nlYwio45/k=; b=wUdAlt3w5Pn/2o95DLx+nJ9qwx9mtJS6ksnPCmnwateNFx0GSrWbXrhSTP7PAlD2mv VFm2E5GiULgyIXJwZ1GO5fRzO1R+BF2U/Da5CYBX/cLRugm4ntHLh3jFrwDU7vmYLOQs bRuai3kEFZJkyNVfSH3DzuzvJ1NPCMFv3+hsFJbAb/nyKUSjFjXbmA+uMLEX5Dnx+x1E FM2jpkIE7sKLXeyCodFdJA9OBy+USLhLS3utdxqGASGv26JwUQJp+6L5oBke/MWaxeUz NsbDpozbJgoKfRRNT7Jk3C1JYCZc+Up9I9RiFCAaaJXYSaPSz0YnsE7i8Y+7nySDLUAN QVkA== X-Gm-Message-State: AO0yUKXbFoLY9ujQcToEKQnZymyY2WnllU2MOWoOZMHf2TxhkF1Sdc5B ywe7rdaGydVo4/w9tDjfpO2ZPktSTkpegTjioSk= X-Google-Smtp-Source: AK7set9Zy3kfeQwUGzqhk1S9QLts6PoPXRZAu2/7xwpJSjtqutDj10dkprpfhTWIwpz6bVgklLv0EqIGGPPVHd+OVKk= X-Received: by 2002:a05:6870:f90e:b0:177:cead:943f with SMTP id ao14-20020a056870f90e00b00177cead943fmr1051089oac.9.1679193018266; Sat, 18 Mar 2023 19:30:18 -0700 (PDT) MIME-Version: 1.0 References: <20230304103851.18965-1-pali@kernel.org> <20230305114634.h6wyi26ohuzuamfg@pali> <20230305160416.xc7wlzmkaociwcf7@pali> <20230306184023.iw5yhp6ofaftlbge@pali> In-Reply-To: <20230306184023.iw5yhp6ofaftlbge@pali> From: Martin Rowe Date: Sun, 19 Mar 2023 02:30:07 +0000 Message-ID: Subject: Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot To: =?UTF-8?Q?Pali_Roh=C3=A1r?= Cc: u-boot@lists.denx.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.39 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.8 at phobos.denx.de X-Virus-Status: Clean On Mon, 6 Mar 2023 at 18:40, Pali Roh=C3=A1r wrote: > On Monday 06 March 2023 11:15:35 Martin Rowe wrote: > > On Sun, 5 Mar 2023 at 16:04, Pali Roh=C3=A1r wrote: > > > Could you try another test by completely erasing BOOT0, BOOT1 and USE= R > > > > data? And see what BootROM prints. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > BootROM - 1.73 > > > > Booting from MMC > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > BootROM: Bad header at offset 00000000 > > BootROM: Bad h > > Trying Uart > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Originally I though that I did not understand disassembled bootrom code > correctly but this logs proves that I did it correctly. Log is very > strange. > > There is a loop which tries partition numbers 0x1, 0x2, ... 0x9, 0xa. > > And if I'm looking at the bootrom code correctly it does bit-AND > operation on partition number with constant 0x7 and result is set into > mmc register 179 (partition_config). > > So if I understand it correctly it means that bootrom automatically > clears boot_ack and boot_partition. And into partition_access it sets > the partition number. Hence numbers 0x9 and 0xa are trimmed and > aliased to 0x1 and 0x2; and number 0x8 overflows to 0x0. > > Completely strange behavior and probably against how HW mmc boot > partitions should be used. > > eMMC spec defines: > partition_access (low 3 bits of mmc 179/partition_config register): > 0x0 : No access to boot partition (default) > 0x1 : R/W boot partition 1 > 0x2 : R/W boot partition 2 > 0x3 : R/W Replay Protected Memory Block (RPMB) > 0x4 : Access to General Purpose partition 1 > 0x5 : Access to General Purpose partition 2 > 0x6 : Access to General Purpose partition 3 > 0x7 : Access to General Purpose partition 4 > I can only set 0, 1, 2, and 7; the others result in `exit not allowed from main input shell.` > I guess that you do not have general purpose partitions layout on emmc > and RPMB is not used too. So technically only 0x0, 0x1, and 0x2 are > available. > > To confirm my theory, could you try to do following tests? > > 1. Check u-boot's "mmc partconf" settings are not preserved across > reboots. > The only part that seems to be preserved is the partition_enable; ack and access both reset to 0. > 2. Put valid image into userdata partition; erase boot 0 and boot 1; and > post bootrom output. There should be 7 invalid attempts with Switching > BootPartitions message. > 7 invalid attempts before it finds u-boot in the userdata partition: BootROM - 1.73 Booting from MMC BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000) > 3. Take valid image, invalidate kwb header checksum and put it on boot0; > plus erase boot1 and user. Bootrom should print "Invalid header > checksum" message and it should be two times. Once for 0x1 and second > time for overflowed 0x9. > Changing just the checksum at 0x1F results in BootROM producing no output and just hanging. I've tried on each boot partition (with the others zeroed) and can't get any results at all. I also tried a valid header and zeroes for the rest of the image; same result.