From mboxrd@z Thu Jan 1 00:00:00 1970 From: Soeren Moch Date: Tue, 28 Jan 2020 18:23:07 +0100 Subject: [PATCH] board: tbs2910: Add support for generic distro configuration In-Reply-To: <20200128180228.38a81620@primarylaptop.localdomain> References: <20200125014240.18126-1-GNUtoo@cyberdimension.org> <97d6009f-a53f-ed2a-8159-ffecd25c9cd1@web.de> <20200126001548.79486262@primarylaptop.localdomain> <20200128180228.38a81620@primarylaptop.localdomain> Message-ID: <3f334d60-dfd8-abb4-c2ec-f2cbad53f3e2@web.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 28.01.20 18:02, Denis 'GNUtoo' Carikli wrote: > On Sun, 26 Jan 2020 01:40:13 +0100 > Soeren Moch wrote: >>> Ahh ok, now I understand. That probably explains the repeated size >>> issues. >> Why? With SPL+u-boot proper it would be even worse, since then there >> is a gap between SPL and u-boot, u-boot starts at higher address in >> eMMC, and it would not be smaller. And this 2-stage boot would break >> the documented u-boot update procedure, since we have to flash 2 >> files then. > I assumed that in some conditions, the bootrom could load only the SPL > in sram. Once loaded, the SPL would initialize the RAM, detect the boot > media, and fetch u-boot.img from it, and execute it. It is different here. i.MX6Q boot rom loads a imx file. This initializes the DDR controller first, then loads the executable payload, u-boot.bin in this case. So there is no restriction from SRAM size, as long as the DDR settings are fixed, what is the case for tbs2910. > > I also hoped the the SPL would have been significantly smaller than the > current u-boot.imx image. It would be. But then you need the u-boot.bin in addition to the SPL.imx , with all the problems explained earlier. > > In the meantime, I'll send a v2 with some additional patches to reduce > the size of the resulting u-boot.imx. As already explained, this is not necessary now. Soeren > > Denis.