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 70079C4332F for ; Sat, 15 Oct 2022 19:47:10 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E0EA784ECA; Sat, 15 Oct 2022 21:47:07 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="nMvWgDI+"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 72C4A84E2A; Sat, 15 Oct 2022 21:47:06 +0200 (CEST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 EEFF584E2A for ; Sat, 15 Oct 2022 21:47:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-wm1-x332.google.com with SMTP id bg9-20020a05600c3c8900b003bf249616b0so6485366wmb.3 for ; Sat, 15 Oct 2022 12:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EnACT2Ir5DO0+4nPXDCGMiNdD9Fx6sRoehXx1j8hbaY=; b=nMvWgDI+JRYavnEidnZfqi6BNz1a93vS0k5kyuM1R0gLEXikRhnXG3dMoDvR1b4wGm 8V10BS38zN3Bw3Z2sogvJ0u89ZSgYP9N5U5L7FPEoDl3DJJCaMvfy1lFxKjyCg2V1N6g Kz19muakbT0Cky2gjStYHRf6YFiYo7SU4/tuE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=EnACT2Ir5DO0+4nPXDCGMiNdD9Fx6sRoehXx1j8hbaY=; b=M7dd+qdEY07OHLGiR31mge9XEn0XerSU8o/k3tSoPDMO3mFNYL7OXgm3uN6RCWC5aF x77BnBuUiNIt+WN7vTFuvOXIQkcP7QWxGA+id9X0HiVFLn/fs6RzT3jzqdjG4IV8397d DsZBvKHFE04XMOszY+MMG4ccxjZ1mxtpoCb4PC/YUIuNgeVtSFkwO5vxtLUomY4L+RNB f16lFH4viqBENWHZLO9VH5g7FnsNkbBups+rVscxeG36Gre+yjUCgO2gCdRb+uZo0AOi GWnjnP0FEbzwnFz1RJ3WGNazbyMlKKdf1wCt7CZ2taNgN3B1erYzb3/eEHKfxC6k1Yy2 nlgQ== X-Gm-Message-State: ACrzQf0Qqvq1J0nXHs1EpqXgPJdkJqmKuqr898B2PxsDfMiQvvPxJWrN 0WH1pK1LmZPtUytXpEIQO4HVEHAS7ND2n/Ei23c2QA== X-Google-Smtp-Source: AMsMyM5fz3xpfKCawXICMKFrSgfdAiKrxnjkyvUnhOaKEPahxvEQPAW7jILVv5qxyrTmQYOmWezKAjPzUJQzABbq2QY= X-Received: by 2002:a05:600c:5254:b0:3b5:99c:9be1 with SMTP id fc20-20020a05600c525400b003b5099c9be1mr2602524wmb.172.1665863223301; Sat, 15 Oct 2022 12:47:03 -0700 (PDT) MIME-Version: 1.0 References: <20221014205234.19385-1-msuchanek@suse.de> <1774657c-51cb-fde7-7f65-a76b8cdcd5f9@gmx.de> <3558da2e-3e66-0b66-cf77-29106653beec@gmx.de> In-Reply-To: From: Simon Glass Date: Sat, 15 Oct 2022 13:46:51 -0600 Message-ID: Subject: Re: [PATCH v2] tests: Build correct sandbox configuration on 32bit To: Heinrich Schuchardt Cc: u-boot@lists.denx.de, Michal Suchanek Content-Type: text/plain; charset="UTF-8" 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.6 at phobos.denx.de X-Virus-Status: Clean Hi Heinrich, On Sat, 15 Oct 2022 at 13:29, Heinrich Schuchardt wrote: > > > > Am 15. Oktober 2022 21:24:36 MESZ schrieb Simon Glass : > >Hi Heinrich, > > > >On Sat, 15 Oct 2022 at 13:05, Heinrich Schuchardt wrote: > >> > >> On 10/15/22 20:39, Simon Glass wrote: > >> > Hi Heinrich, > >> > > >> > On Sat, 15 Oct 2022 at 12:31, Heinrich Schuchardt wrote: > >> >> > >> >> On 10/15/22 19:53, Simon Glass wrote: > >> >>> Hi Michal, > >> >>> > >> >>> On Fri, 14 Oct 2022 at 14:53, Michal Suchanek wrote: > >> >>>> > >> >>>> Currently sandbox configuration defautls to 64bit and there is no > >> >>>> automation for building 32bit sandbox on 32bit hosts. > >> >>>> > >> >>>> Use _LP64 macro as heuristic for detecting 64bit targets. > >> >>>> > >> >>>> Signed-off-by: Michal Suchanek > >> >>>> --- > >> >>>> > >> >>>> Changes in v2: > >> >>>> simplify and move detection to kconfig > >> >>>> > >> >>>> --- > >> >>>> arch/sandbox/Kconfig | 18 +++--------------- > >> >>>> scripts/Kconfig.include | 4 ++++ > >> >>>> 2 files changed, 7 insertions(+), 15 deletions(-) > >> >>> > >> >>> Reviewed-by: Simon Glass > >> >>> > >> >>> My only question is whether we can allow building the 32-bit version > >> >>> on a 64-bit machine? That would need a separate option I think, to > >> >>> say: > >> >>> > >> >>> I don't want you to automatically determine HOST_32/64BIT. Instead, > >> >>> use 32 (or 64). > >> >>> > >> >>> This is along the lines of what Heinrich is saying, except that I > >> >>> strongly feel that we must do the right thing by default, as your > >> >>> patch does. > >> >> > >> >> The whole point of phys_addr_t and phys_size_t is that it can be 64bit > >> >> or 32bit on ilp32. > >> >> > >> >> With this patch we cannot build with CONFIG_PHYS_64BIT=y on ilp32 and > >> >> that is bad. > >> >> > >> >> 32 bit phys_addr_t on lp64 is irrelevant for actual hardware but this is > >> >> what we currently test with sandbox_defconfig on Gitlab CI. > >> >> > >> >> My patch is ending up in the same behavior as Michal's patch except that > >> >> it allows to have 64bit phys_addr_t on ilp32. > >> > > >> > It needs to automatically default to 32 or 64 bit depending on the > >> > host. If the user wants to fiddle with Kconfig to force it to the > >> > other one, that should be possible to. > >> > > >> > It looks like your patch requires manual configuration, but perhaps I > >> > just misunderstood it? > >> > >> __LP64__ is a symbol defined by the compiler when compiling for 64bit > >> and not defined when compiling for 32bit systems. There is nothing > >> manual about it. > >> > >> My patch uses this symbol to replace HOST_32BIT and HOST_64BIT. > >> > >> Michal's patch compiles a program tools/bits-per-long.c that ends up > >> returning 64 on 64 bit systems (where __LP64__ is defined) and 32 on 32 > >> bit systems (where __LP64__ is not defined) and then chooses HOST_32BIT > >> and HOST_64BIT accordingly. This part of Michal's patch is not wrong. > >> The solution is only overly complicated. > >> > >> What has to be chosen manually with both patches is PHYS_64BIT e.g. by > >> selecting sandbox64_defconfig instead of sandbox_defconfig. > >> > >> Unfortunately Michal did not understand that PHYS_64BIT=y, HOST_32BIT=y > >> is a necessary test scenario and introduced an invalid dependency. > >> > >> With my patch sandbox64_defconfig on a 32bit system uses 64bit phys_addr_t. > >> > >> With Michal's patch sandbox64_defconfig on a 32bit system uses 32bit > >> phys_addr_t. > > > >That's all great, thank you, but please can you address my actual question? > > Your question in this thread was if my patch requires extra manual configuration compared to Michal's patch and the answer was no. > > What other question do you have? "It needs to automatically default to 32 or 64 bit depending on the host. If the user wants to fiddle with Kconfig to force it to the other one, that should be possible to." I am not talking about anyone's patch, actually, just trying to state what I think should happen. Regards, Simon