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 5468FC0015E for ; Thu, 13 Jul 2023 22:35:08 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1A96886CEA; Fri, 14 Jul 2023 00:35:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com 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=ti.com header.i=@ti.com header.b="oXTAXvz3"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 000E786CEC; Fri, 14 Jul 2023 00:35:04 +0200 (CEST) Received: from fllv0016.ext.ti.com (fllv0016.ext.ti.com [198.47.19.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 875E586CDF for ; Fri, 14 Jul 2023 00:35:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=nm@ti.com Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 36DMYt1n010199; Thu, 13 Jul 2023 17:34:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1689287695; bh=+agRxx1bcP5ewrcypXjycxe2Fqo8mqldVXv6WY2+wMg=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=oXTAXvz3whVd/Ki1f+rm2k0O9TIkyb6sHe4QcCGMz/KzNMXaL9ZvaHFN+P9Zv2ISZ rdknquLElyUZRGGU5Y9LZXT6KfBrwWfHgkhUajrEEnZrZRbxjn2d+dwEFvdAF3sUqQ ur+Ta6mjEuYvBzbPxUZwMzUFhQzHqzIPCdLw7hTU= Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 36DMYtds109017 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 13 Jul 2023 17:34:55 -0500 Received: from DLEE106.ent.ti.com (157.170.170.36) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Thu, 13 Jul 2023 17:34:55 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE106.ent.ti.com (157.170.170.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Thu, 13 Jul 2023 17:34:55 -0500 Received: from localhost (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 36DMYtAa065060; Thu, 13 Jul 2023 17:34:55 -0500 Date: Thu, 13 Jul 2023 17:34:55 -0500 From: Nishanth Menon To: Simon Glass CC: Jason Kacines , Andrew Davis , Vignesh Raghavendra , Bryan Brattlof , Praneeth Bajjuri , Tom Rini , Subject: Re: [RFC PATCH 0/3] Minimal platform configuration Message-ID: <20230713223455.bngcabgcebxqn6sr@prison> References: <20230711212048.1340990-1-j-kacines@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 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 08:00-20230712, Simon Glass wrote: > Hi Jason, > > On Tue, 11 Jul 2023 at 16:28, Jason Kacines wrote: > > > > When someone attempts to bring up a custom board using TI SoCs (am62x in > > this case), it often takes several days for someone to reduce the > > current configuration from the TI EVM/SK boards to a configuration that > > works for their board. > > > > The goal of these changes is to allow for a minimal boot configuration > > to exist within UBoot that someone can access directly in order to > > test their boards for a sign of life before beginning development. This > > is all done with the hope to increase ease of use and reduce the > > upbringing process from several days to a few hours. > > > > With the use of fragments, the base defconfigs reside in configs/ and > > the config fragments reside in board/../ > > > > There is still quite a lot of board specific code inside board_init_f() > > that will need attention later, however this series begins the process > > of splitting the am62x's configs into a separate generic defconfig > > everyone can use for new board wakeups with individual board/ti/*.config > > fragments for each board varient. > > How about setting up some common defaults for your arch using Kconfig, > so that the board defconfigs are much smaller? > > In general, boards in U-Boot have far too many individual settings. > Most of them should use a sensible default. > > Going in the direction you have here just continues that tradition, > inventing what I feel is an unnecessary solution. Challenge here is SRAM. When we enable OSPI for example or USB DFU for a group of our devices -> they follow a specific pattern of CONFIG options, which over and over again, we mess up by having individual config options being updated. This is similar in nature to the kernel config fragment motivation as well - in fact just worse with SRAM limitations with which SPL or early stages of bootloaders need to function with. Look at today's list: am65x_evm_a53_defconfig am65x_evm_r5_defconfig am65x_evm_r5_usbdfu_defconfig am65x_evm_r5_usbmsc_defconfig am65x_hs_evm_a53_defconfig am65x_hs_evm_r5_defconfig The usbdfu or msc stuff just replicates it self over and over as people enable that for next TI SoC and so and so forth. Other patterns are stuff like Android configurations or distro boot configurations - or uefi - instead of each vendor re-discovering the right options, the opens up the possibility of standardized fragments that any platform that chooses can pick. I am with you that there are too many individual settings at times, and there is a need to keep the defconfigs small as well. One thing we have to fight against constantly is boot time memory availability and speed of boot requirements. but those are details of the exact Kconfig options enabled etc.. for us at least, config fragments opens up a sustainable and low-fail option of consistently enabling features across SoCs and platforms. I think many folks who struggle with the same will concur as well. We are definitely open to following a structured set of rules when and how it should be used.. but hopefully, this helps explains? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D