From nobody Sun Nov 9 14:31:53 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1551210020077442.9648345684783; Tue, 26 Feb 2019 11:40:20 -0800 (PST) Received: from localhost ([127.0.0.1]:60276 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyiaK-0006GH-2H for importer@patchew.org; Tue, 26 Feb 2019 14:40:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyiV0-0002IR-Ds for qemu-devel@nongnu.org; Tue, 26 Feb 2019 14:34:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gyiUu-0006MI-Ow for qemu-devel@nongnu.org; Tue, 26 Feb 2019 14:34:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48504) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gyiUf-0005xV-98; Tue, 26 Feb 2019 14:34:21 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 39A087E9C4; Tue, 26 Feb 2019 19:34:13 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-92.ams2.redhat.com [10.36.116.92]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CA7701001DDF; Tue, 26 Feb 2019 19:34:12 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 217931133056; Tue, 26 Feb 2019 20:34:08 +0100 (CET) From: Markus Armbruster To: qemu-devel@nongnu.org Date: Tue, 26 Feb 2019 20:34:03 +0100 Message-Id: <20190226193408.23862-7-armbru@redhat.com> In-Reply-To: <20190226193408.23862-1-armbru@redhat.com> References: <20190226193408.23862-1-armbru@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 26 Feb 2019 19:34:13 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 06/11] sam460ex: Don't size flash memory to match backing image X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, qemu-block@nongnu.org, alex.bennee@linaro.org, mreitz@redhat.com, qemu-ppc@nongnu.org, lersek@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Machine "sam460ex" maps its flash memory at address 0xFFF00000. When no image is supplied, its size is 1MiB (0x100000), and 512KiB of ROM get mapped on top of its second half. Else, it's the size of the image rounded up to the next multiple of 64KiB. The rounding is actually useless: pflash_cfi01_realize() fails with "failed to read the initial flash content" unless it's a no-op. I have no idea what happens when the pflash's size exceeds 1MiB. Useful outcomes seem unlikely. I guess memory at the end of the address space remains unmapped when it's smaller than 1MiB. Again, useful outcomes seem unlikely. The physical hardware appears to have 512KiB of flash memory: https://eu.mouser.com/datasheet/2/268/atmel_AT49BV040B-1180330.pdf For now, just set the flash memory size to 1MiB regardless of image size, and document the mess. Cc: BALATON Zoltan Signed-off-by: Markus Armbruster Reviewed-by: Alex Benn=C3=A9e Reviewed-by: BALATON Zoltan --- hw/ppc/sam460ex.c | 41 ++++++++++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c index 75250d49e4..0c919529f8 100644 --- a/hw/ppc/sam460ex.c +++ b/hw/ppc/sam460ex.c @@ -91,32 +91,43 @@ struct boot_info { =20 static int sam460ex_load_uboot(void) { + /* + * This first creates 1MiB of flash memory mapped at the end of + * the 32-bit address space (0xFFF00000..0xFFFFFFFF). + * + * If_PFLASH unit 0 is defined, the flash memory is initialized + * from that block backend. + * + * Else, it's initialized to zero. And then 512KiB of ROM get + * mapped on top of its second half (0xFFF80000..0xFFFFFFFF), + * initialized from u-boot-sam460-20100605.bin. + * + * This doesn't smell right. + * + * The physical hardware appears to have 512KiB flash memory. + * + * TODO Figure out what we really need here, and clean this up. + */ + DriveInfo *dinfo; - BlockBackend *blk =3D NULL; - hwaddr base =3D FLASH_BASE | ((hwaddr)FLASH_BASE_H << 32); - long bios_size =3D FLASH_SIZE; - int fl_sectors; =20 dinfo =3D drive_get(IF_PFLASH, 0, 0); - if (dinfo) { - blk =3D blk_by_legacy_dinfo(dinfo); - bios_size =3D blk_getlength(blk); - } - fl_sectors =3D (bios_size + 65535) >> 16; - - if (!pflash_cfi01_register(base, NULL, "sam460ex.flash", bios_size, - blk, 64 * KiB, fl_sectors, + if (!pflash_cfi01_register(FLASH_BASE | ((hwaddr)FLASH_BASE_H << 32), + NULL, "sam460ex.flash", FLASH_SIZE, + dinfo ? blk_by_legacy_dinfo(dinfo) : NULL, + 64 * KiB, FLASH_SIZE / (64 * KiB), 1, 0x89, 0x18, 0x0000, 0x0, 1)) { error_report("Error registering flash memory"); /* XXX: return an error instead? */ exit(1); } =20 - if (!blk) { + if (!dinfo) { /*error_report("No flash image given with the 'pflash' parameter," " using default u-boot image");*/ - base =3D UBOOT_LOAD_BASE | ((hwaddr)FLASH_BASE_H << 32); - rom_add_file_fixed(UBOOT_FILENAME, base, -1); + rom_add_file_fixed(UBOOT_FILENAME, + UBOOT_LOAD_BASE | ((hwaddr)FLASH_BASE_H << 32), + -1); } =20 return 0; --=20 2.17.2