From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Date: Thu, 14 Aug 2014 22:39:19 +0200 Subject: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings In-Reply-To: <53ED1730.8070009@wwwdotorg.org> References: <1405352998-7707-1-git-send-email-holler@ahsoftware.de> <1405352998-7707-2-git-send-email-holler@ahsoftware.de> <53D9761D.8050304@wwwdotorg.org> <20140731195130.GT19374@bill-the-cat> <53DA9F98.9050506@wwwdotorg.org> <53EC7265.2080909@ahsoftware.de> <53ECDA9F.4000604@wwwdotorg.org> <53ED1047.3000607@ahsoftware.de> <53ED1339.7050905@wwwdotorg.org> <53ED1504.9050805@ahsoftware.de> <53ED1730.8070009@wwwdotorg.org> Message-ID: <53ED1E77.4080509@ahsoftware.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 14.08.2014 22:08, schrieb Stephen Warren: > On 08/14/2014 01:59 PM, Alexander Holler wrote: >> Am 14.08.2014 21:51, schrieb Stephen Warren: >>> On 08/14/2014 01:38 PM, Alexander Holler wrote: >>>> Am 14.08.2014 17:49, schrieb Stephen Warren: >>>>> On 08/14/2014 02:25 AM, Alexander Holler wrote: >>>> >>>>>> As I've just remembered where I did see your name before, the config >>>>>> for >>>>>> the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to >>>>>> execute commands when using uEnv.txt. >>>>>> >>>>>> It's easily done with something like the following: >>>>>> >>>>>> "env import -t -r $loadaddr >>>>>> $filesize;" \ >>>>>> "if test -n \"$uenvcmd\"; then " \ >>>>>> "echo \"Running uenvcmd >>>>>> ...\";" \ >>>>>> "run uenvcmd;" \ >>>>>> "fi;" \ >>>>> >>>>> My intention was that uEnv.txt be used to set up environment >>>>> variables, >>>>> not to allow its use for custom scripts. >>>>> >>>> >>>> Sure. In most cases changing the predefined available variables is >>>> enough. But it's a very hand option if someone wants or needs to do >>>> stuff which can't be done by just changing some environment variables >>>> (one never knows what ideas people will have). >>> >>> For such presumably non-standard things, why can't the user simply edit >>> $bootcmd, and pre-pend whatever they want? >> >> Depends on when the bootcmd will be constructed. Usually that is done >> after having read uEnv.txt to include variables defined in uEnv.txt in >> bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be >> overwritten. > > What would over-write bootcmd? None of the boards I've looked at > auto-generates bootcmd. bootargs perhaps (which is a string passed to > the kernel) but not bootargs (which is a U-Boot command sequence that > U-Boot executes automatically at boot). > > If some board does auto-generate bootcmd, I'd suggest that it not. The > static bootcmd could execute some kind of user-(or uenv-)set variable > and/or the auto-generation of bootcmd could happen before uenv.txt was > pulled in, so that whatever was in uenv.txt would have ultimate "power". Ah, yes. Sorry, I confused bootcmd with bootargs (I don't live in u-boot and just fiddle once a year or such with it). But overwriting bootcmd needs to read uEnv.txt in PREBOOT (or how it is named). I originally have read uEnv.txt in the bootcmd itself, so overwriting it didn't work. But I don't want to dive too deep into that discussion, as I think it's up to the board-maintainers to write the config however they want and seem to fit for there users. I've just mentioned the uenvcmd, because it was the first, I've added to my u-boot for the rpi (to have the same interface I use with my other boards). ;) Regards, Alexander Holler