From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Subject: Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot Date: Tue, 16 Feb 2016 08:33:32 -0500 Message-ID: <20160216133332.GT23166@bill-the-cat> References: <1453999186-18747-1-git-send-email-sjg@chromium.org> <20160216121709.GR23166@bill-the-cat> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftsvpRfm7AHRcupw" Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=D90cJxe3qxVQ+Dl/F657qDbcfJpzdrxdMGTlURo71BA=; b=qtVYOKChUPkFePaa8MisAg+A+aJh87bWER/bTPgmC5oMpD+Qxx6BOr2L0Q9+BoU7k9 2JDted1DPM0LjDZJCm49djSpPJMbtFBoW4wohVMrvlE3vJ4yPiaztP8fKxu6HEHcIhB9 JyCo5rbsqPXGx11CAVsIMFpSBDI4Mj72gK36U= Content-Disposition: inline In-Reply-To: Sender: devicetree-compiler-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: To: Masahiro Yamada Cc: Joe Hershberger , U-Boot Mailing List , Jerry Van Baren , Ian Campbell , Devicetree Compiler --ftsvpRfm7AHRcupw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 16, 2016 at 09:30:44PM +0900, Masahiro Yamada wrote: > 2016-02-16 21:17 GMT+09:00 Tom Rini : > > On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote: > >> Hi Simon, > >> > >> > >> 2016-01-29 1:39 GMT+09:00 Simon Glass : > >> > We need a way to support more than one board per binary in U-Boot wi= th > >> > device tree. Various methods have been discussed. The one that seems= to make > >> > the most sense is to adjust SPL so that it can load a FIT which cont= ains > >> > U-Boot and several device tree binaries. This is how things with wit= h Linux: > >> > load a FIT and select the correct device tree to pass to Linux. > >> > >> I've just skimmed over the git-logs, but I am confused. > >> > >> > >> Please makes it clearer why this is useful. > >> In your way, how SPL is handled? > >> > >> SPL is much more board-specific than U-Boot proper. > >> So, I assume SPL would remain as a per-board image > >> even after achieving one U-Boot proper for multi-boards. > >> > >> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot= proper. > >> > >> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be > >> generated by one-shot > >> and by one defconfig. > >> > >> > >> But, we would still have to do > >> > >> make board_a_defconfig && make > >> make board_b_defconfig && make > >> make board_c_defconfig && make > >> > >> to generate SPL for each of the three. > >> Is this correct? > >> > >> > >> Supposing my guess is correct, this series would not contribute > >> to decreasing the number of defconfig files. > >> > >> > >> > >> Please explain which problem you are solving with this series. > > > > It won't be just one board. We need this so that we can replicate > > existing (and very useful) functionality. Today, am335x_evm_config > > supports Beaglebone White, Beaglebone Black (could be faked enough for > > U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART > > AM335x IDK EVM. Each of these is different enough that they have their > > own DT that we will need to pass up to U-Boot, and their own config > > file. With Simon's series we'll be able to move am335x_evm_config up to > > DM in SPL and possibly even remove some of the am335x_evm subconfigs we > > have today, once those specific options also move to Kconfig. >=20 > So, this series is useful to merge some boards > that are different enough to have their own DT, > but that are similar enough to share one SPL binary, correct? Yes. It _may_ even be useful later on to support a more broad set of boards than we do today (ie it's not impossible that one binary could support the TI AM43xx EVMs as well, or all TI EVMs that have the EEPROM that identifies the model, for some narrow scope of boot devices). --=20 Tom --ftsvpRfm7AHRcupw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJWwyUsAAoJEIf59jXTHXZSxmIP/36K842Lc1gKme83Gc4MQl7y nTINGMPyb3yGWz8wVKAgd7H7ut8bb11QXThpDVjYBuCwMbMkPRH2dHKF7r7K91U6 er4HdMZ2w/6cI6EvkGxiz347TnSerd6Bt1yS0SK13rBBfYssizsFiTd1dHW2rwBP aqwqVWri6dI/wYX0oz+MfoKloYHBlONuZIJv2uomcEfAWUKQViPqRrXOzraJcued b5sOlYwl4OKLZjmIGYzv3i4CDpb/jUpq6whKBvJRyQMrQJyfka21afkztgYEZfBR YhURiy7VS6cV3KK6Whg+laF4TYn2Nry16VK+KI/07RAIfP8uM1KjuEJXJQ+YAMQo aPw1RMOdwftnyqKVkeRmfzg1goxxcEGc4ZcDzA6lijPuWMQpEHZw/aI/Y9shEF46 cEQPz2PaJVm/ziClFzKUe5kPlkmj79rcU06PH9fKasAmnlFqQCoo4aHj63s4FBX5 7b8wWq0OkLENcpAGQecxBv/bjgp/n/BcJfisrIYh2lOEBSt2Sd5aKpTUx+w+2qE8 cnbhCSGb0VsPaG15UxOC8zlbornMSntknC5k8yAPgdBIjjNjVQ7+0LpY4KQk0viG JEuvMRBqMb7xX4AJIqw4G/tITBQvUb3tHdYqLy9Mf2F6YusJwtmdh79e8ac0sY7M UsXC/8hkiM5Qzuh1fcAg =FgNO -----END PGP SIGNATURE----- --ftsvpRfm7AHRcupw--