From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Sat, 3 Sep 2016 11:40:40 +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: <11f4e24d-17c2-69a6-ba59-078e3bbfe09f@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Petr, On 03/09/2016 01:15, Petr Kulhavy wrote: > 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. This is why they have two different defconfigs. > 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? I am noit a Buildroot expert, someone else can better point you in the right direction. I will expect that you need a second target. If I had to do thuis in Yoct, I will tend to add a new recipe to build .imx variant. Best regards, Stefano Babic > > > 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 > > -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================