From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Wed, 12 Apr 2017 10:59:27 +0200 Subject: [U-Boot] Unbricking process with separate environment binary? In-Reply-To: References: <20170411094053.488cd070@jawa> Message-ID: <20170412105927.35d1eb47@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi John, > Hi Lukasz, > > On Tue, Apr 11, 2017 at 12:40 AM, Lukasz Majewski > wrote: > > Hi John, > > > >> Instead of having 2 builds of u-boot, one which defaults to > >> fastboot and one for normal booting, is it possible to have one > >> u-boot binary and a separate environment piece (especially for > >> bootcmd, but maybe also for some scripts)? > > > > If I might ask - where your envs are stored? Do they have a separate > > area in NAND or eMMC memory? > > > > If yes, then I suppose that you also have the possibility to write > > data to this memory in the production? > > The production redundant environment will have its own area in eMMC. > The environment could be written to the eMMC from the development host > after running fastboot or ums in u-boot, but the question is how > fastboot/ums gets run when starting with a completely blank, freshly > soldered, non-partitioned board. I've already used two approaches (with TI SoC): - Use "factory" SD card (if the slot is available) with tunned u-boot (by altering envs) - Use serial port (you mentioned that you want to talk with the board with 'expect') to transfer SPL(MLO)/u-boot The above option though is relatively slow, but at least for me it worked reliably. - Maybe you can boot from USB stick (I don't know what is your target SoC). > > > If yes (again) then maybe it would be better to only adjust (and > > replace) the default environment on board? > > > > For example: > > > > 1. You extract envs by using the scripts/get_default_envs.sh - > > modify it and then use mkenvimage to produce new env image. > > > > 2. You store u-boot (with NAND/eMMC not programmed) to your device. > > This u-boot has default environment with instructions for flashing. > > > > 3. You flash your final envs prepared in point 1. > > It seems that flashing the environment binary, or any other piece, > first requires something running on the target to accept the bits and > flash. Yes, correct. > Setting CONFIG_BOOTCOMMAND at compile time will do, but > ideally, I can use the same bootloader binary and decide the bootcmd > at deploy time. Personally, I would go for some script file (like boot.scr), which then would be imported to u-boot envs. That file can be also easily replaced at factory time, by just changing the file content. > > Thanks, > John Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de