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 AA966EB64DC for ; Tue, 11 Jul 2023 10:34:59 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3D7968681C; Tue, 11 Jul 2023 12:34:57 +0200 (CEST) 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="FMNyL6Nr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 79E9486822; Tue, 11 Jul 2023 12:34:56 +0200 (CEST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 F02388681B for ; Tue, 11 Jul 2023 12:34:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=virag.david003@gmail.com Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-991fe70f21bso698288566b.3 for ; Tue, 11 Jul 2023 03:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689071693; x=1691663693; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=k85xhDoewZqBckHAA6B4ER+j0reH5SdLzhRgtYXJLOY=; b=FMNyL6NrGmiz/SHcYZRd0EorkQW/gRJ9pPx9pyxxO71GhRsjGkjh/wH80cYamn8Fov j1KiIu/Yltif+NW3n85uaOKdH3HHw+RVyHBeDtTiHYgqJKFTXs/6n/OqzTOa02y7Ge+H NKBxi4zvc6Kp5gYuBGC8jNCBqJxCdo40Z9lh7muay2Exg+enIPalUK61wrtqsccV6mL5 iQJgVhudf5H91V9IY8c1HMSDEUhgJwNeBGg651ZQVeTiKN6RhZWqgcaUt2LMjH1SMgpe KBryFQr2buVpcmi7Bi72RxbEULjthujvYoVktHvxuow1a7JF39mNtqcksyCLXT3oA+5R kPTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689071693; x=1691663693; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=k85xhDoewZqBckHAA6B4ER+j0reH5SdLzhRgtYXJLOY=; b=k/PcFimapTrzYwRUtlUSOJwTWo/eLZ/MJy/I9n+VDb3lNcqqNdx7MMpAP1Ue7G/O0J h7JpKb1YBIxTE2B6A7iQLU6sTNR+o2jGvIlGhEAPAw9TJiuJVikQ2F4NPHqwQk60ij4d RjWI9KTBQVMoZNPresFLNuANFd2iQMF4tdXYy7VsTrx3wnVJtKbsbx3rexIYbI2OpU6n 9aTtPmUqJbJVN5WggMUZ1zf4PNOTJasssXHPqBwPH276Ym7Rh4YlsvQjy3Gu/E4Sjlml kz6wIx6HT4kegODGnt92iLSjvB9e9eMs1ft4CINk4QC/Qec8B456tBZAtnPhEb0V7y5p rBDA== X-Gm-Message-State: ABy/qLZLkMn79ob8idBAJKje8hLwMzzhxibS/aS5uBjsV1+n329g2iSn pQ8kY++lR1/kQvtO/Pi2cjU= X-Google-Smtp-Source: APBJJlHLqyZpSPpdytVRDNpgse+zrVDH8Wm9aYUr+jcjA4mCZ1exj27ZBA0IK6MLSB83IZfIylG2Vg== X-Received: by 2002:a17:906:100b:b0:992:bc8:58e4 with SMTP id 11-20020a170906100b00b009920bc858e4mr16261153ejm.20.1689071693186; Tue, 11 Jul 2023 03:34:53 -0700 (PDT) Received: from ?IPv6:2a02:ab88:368f:2080:d12e:7ef:c89a:f600? ([2a02:ab88:368f:2080:d12e:7ef:c89a:f600]) by smtp.gmail.com with ESMTPSA id j22-20020a170906411600b00993159ce075sm957487ejk.210.2023.07.11.03.34.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jul 2023 03:34:52 -0700 (PDT) Message-ID: <8fa4eead45bf25f5fa4611c71e68d21a94b094a7.camel@gmail.com> Subject: Re: [BUG] fdt_pack_reg in common/fdt_support.c can cause crash from unaligned access From: David Virag To: Simon Glass , Tom Rini Cc: u-boot@lists.denx.de Date: Tue, 11 Jul 2023 12:34:51 +0200 In-Reply-To: References: <20230710201339.GZ148062@bill-the-cat> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 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, 2023-07-10 at 15:38 -0600, Simon Glass wrote: > Hi, >=20 > On Mon, 10 Jul 2023 at 14:13, Tom Rini wrote: > >=20 > > On Mon, Jul 10, 2023 at 01:45:46PM -0600, Simon Glass wrote: > > > Hi David, > > >=20 > > > On Sun, 9 Jul 2023 at 19:11, David Virag > > > wrote: > > > >=20 > > > > Hi, > > > >=20 > > > > I'm trying to port U-Boot to a new board (Samsung JACKPOTLTE, > > > > ARMv8, > > > > Exynos7885) but when CONFIG_ARCH_FIXUP_FDT_MEMORY is enabled, > > > > the bootm > > > > command leads to an unaligned memory access, which results in a > > > > synchronous abort. > > > >=20 > > > > After a long debugging session, I concluded that fdt_pack_reg > > > > in > > > > common/fdt_support.c writes to unaligned addresses in its for > > > > loop. > > > > In the case of address_cells being 2, and size_cells being 1, > > > > the > > > > buffer pointer gets incremented by 12 in each loop, making the > > > > second > > > > iteration (i=3D1) write a 64bit value to a non 64bit aligned > > > > address. > > > >=20 > > > > Turning the alignment check enable bit (A) off in SCTLR makes > > > > the > > > > function work as intended. I couldn't find code that touches > > > > this bit, > > > > but I may have missed something. I don't think writing in two > > > > parts > > > > should be the fix, but something should be done about this. As > > > > far as I > > > > understand, any arm64 board that has this bit turned on, either > > > > from > > > > previous code or just the initial status of the bit after power > > > > on, > > > > could crash here. > > > >=20 > > > > This is on top of the latest commit as of now > > > > (0beb649053b86b2cfd5cf55a0fc68bc2fe91a430) > > > >=20 > > > > What should be done here? > > >=20 > > > +Tom Rini > >=20 > > ... I was hoping you had an idea Simon. Is this part of the code we > > share with libfdt itself, or one of the helpers we made? Since the offending code is in common/fdt_support.c and not somewhere in lib/libfdt, I'd say it's one of the helpers. >=20 > Hmmm, is the DT itself 64-bit aligned? It needs to be. It should be. I forgot to mention, but I'm loading the DT itself from the FIT image to address 0x82000000. I'm trying to boot a Linux kernel with it. According to uart output, working FDT gets set to 0x82000000, then for some reason gets loaded to 0x8f908000. Both are aligned, so this shouldn't be a problem. Here is the uart output, maybe there's something interesting in it (probably should've provided it earlier): ## Loading fdt from FIT Image at 89000000 ... Using 'alarm' configuration Trying 'fdt' fdt subimage Description: DTB Type: Flat Device Tree Compression: uncompressed Data Start: 0x8a5be9a0 Data Size: 21936 Bytes =3D 21.4 KiB Architecture: AArch64 Load Address: 0x82000000 Hash algo: sha1 Hash value: b289ae4aab26ae514e06ca76b4ad8f3f9c6d6cab Verifying Hash Integrity ... sha1+ OK Loading fdt from 0x8a5be9a0 to 0x82000000 Booting using the fdt blob at 0x82000000 Working FDT set to 82000000 Loading Kernel Image Loading Ramdisk to 8f911000, end 8ffff885 ... OK Loading Device Tree to 000000008f908000, end 000000008f9105af ... OK Working FDT set to 8f908000 "Synchronous Abort" handler, esr 0x96000061, far 0xffb4d28c elr: 000000000001aec8 lr : 000000000001ae70 (reloc) elr: 00000000fff88ec8 lr : 00000000fff88e70 x0 : 0000000000000001 x1 : 0000000000000001 x2 : 0000009000000000 x3 : 0000000090000000 x4 : 000000000000000c x5 : 0000000000000008 x6 : 0000000000000008 x7 : 000000008f908000 x8 : 000000000000004c x9 : 00000000ffb4d0fc x10: 0000000000000003 x11: 0000000000004e78 x12: 00000000ffb4d1f8 x13: 000000008f908000 x14: 00000000ffffffff x15: 00000000ffb4d448 x16: 0000000000000000 x17: 0000000000000004 x18: 00000000ffb4ecb0 x19: 00000000ffb4d28c x20: 0000000000000010 x21: 0000000000000002 x22: 00000000ffb4d390 x23: 00000000ffb4d410 x24: 000000008f908000 x25: 00000000fffcbbc9 x26: 00000000fff70834 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000ffb4d1f0 Code: b8666ac2 71000abf 54000181 dac00c62 (f9000262) Resetting CPU ... resetting ... >From u-boot.map, addresses 000000000001aec8 in elr and 000000000001ae70 in lr should be the fdt_pack_reg function (000000000001ae30). The thing is that the function above does access data unaligned, since... well, the data is not always aligned there. With 64bit address cells and 32bit size cells, even if the first reads are aligned, it will shift in and out of being 32 bits off from aligned. We read 64 bits, increment the ptr by 64 bit, read 32 bits, increment by 32 bits, and read 64 bits again, which is 96 bits from the start. >=20 > Looking at fdt_find_separate() it needs _end >=20 > Looking at arch/arm/cpu/armv8/u-boot.lds I don't see an ALIGN before > _end. >=20 > So perhaps that is the problem? >=20 I don't know about this, but it's not related to the problem I'm running into. > Regards, > Simon Best regards, David