From mboxrd@z Thu Jan 1 00:00:00 1970 From: Petr Kulhavy Date: Sat, 3 Sep 2016 01:15:54 +0200 Subject: [U-Boot] Building u-boot.imx and SPL simultaneously In-Reply-To: References: <226b38f1-0f0f-a997-2272-5bb13d0856bc@jikos.cz> <24f0546a-7a65-45ac-5128-667ff6fb87fa@jikos.cz> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stefano, I need to build two set-ups: 1) SPL + u-boot.img for normal device run out of flash 2) u-boot.imx for initial device load together with fastboot For (2) SPL + kermit + u-boot.img is not an option for me, simply because it is too slow. I agree that the u-boot images in case (1) and (2) do not generally have to be identical. However in my case I don't need them to be different. You are saying that in order to cover my use case(s) I need two defconfigs. Well, ok... But how do I integrate this into Buildroot? For the sake of maintainability, simplification, reducing chance for an error during build I want to have one Buildroot defconfig, run one build command and get all the necessary images. How do I do that with two U-boot defconfigs? On 02/09/16 23:45, Stefano Babic wrote: > Hi Petr, > > On 02/09/2016 20:57, Petr Kulhavy wrote: >> Hi, >> >> you have already brought it to the point - it needs two defconfigs. >> This means double the files in U-boot and second and more important, how >> does it integrate into a tool like Buildroot? >> In other words I'm trying to do it with just one defconfig. >> >> Alltogether I want to build 3 files: >> * SPL which is started by the RBL >> * u-boot.img which is loaded by the SPL from the flash after typing 'c' >> or similar on the terminal >> * u-boot.imx for an initial load of the board via USB if there is no BL >> at all > You are assuming that the two different setups are equivalent: u-boot.ix > against SPL + u-boot.img. It is not, and they have very different > concepts on the basis of two. Well, I see it slightly different. There is some core functionality of u-boot, which is the command interpreter, scripting, drivers, etc. And then there is some one-time HW initialization that needs to be done. There are two different ways of doing the HW initialization: either via RBL and DCD, or via SPL. But after the HW is initialized it comes in both cases to the same functionality. Once the u-boot is started it does not see the SPL and it probably doesn't even know how it was loaded. It just assumes that certain HW is initialized in a certain way. In the end both u-boot.imx and u-boot.img are generated out of the same u-boot.bin, just with different mkimage parameters. > And with imx_usb_loader it is still possible to load the SPL via USB, > and via UART, SPL loads u-boot.img - see README.imx6. That is too slow for my needs. >> All these images plus rootfs and kernel should be an outcome of one >> build in Buildroot. >> >> Since the u-boot.imx is in fact u-boot.img with an extra header > It is not: it is different. If it was just an header, I agree that it is > like building the bootloader in several formats. That happens for > u-boot.bin and u-boot.img, or u-boot.bin and u-boot.imx. > > u-boot.imx has much more as a header: it is contain the DCD tables > according to the FSL documentation that it is interpreted by the RBL. > This is a static setup, because the DCD table is fixed. The RBL sets the > SOC according to the values in the DCD table and has (or it can have) > nothing to do with the SPL+u-boot.img built for the same board. > > On the other side, SPL does not use DCD at all (it could be, but it is > empty), and the setup is done with runtime detection by SPL code. The > u-boot.img built together with SPL depends on it, that means it does not > set again some parts already set by the SPL. That means you cannot > simply exchange u-boot.img or u-boot.imx. I don't want to exchange them. I want to do the same HW initialization which u-boot expects from SPL in the DCD and out of that create the u-boot.imx, which is then directly loaded without SPL. But currently it is not possible. > Generally, we cannot assume that a u-boot.img, behaves as u-boot.imx: it > could be, but it is only luck. Of course, if I want to use two different vesions of u-boot with different sets of commands and features it makes sense to have two defconfigs. But if I want to use the same functionality why should the make process hinder generating the .img and .imx in the same build process? Regards Petr