Wolfgang Denk wrote:
Dear Eric,
In message 4988936E.3070504@boundarydevices.com you wrote:
In the email thread you mentioned above, Detlev mentions 2 alternatives to the "ramenv" command - loading a uImage script and running it via autoscr, or modifying autoscr to be able to raw files (non-uImages). Both of these methods seem cleaner and more flexible at a glance. Is there a specific reason using autoscr wouldn't work for your setup?
The customer requesting this feature operates in a regulated environment with pretty strict rules about separation of code and data. Autoscr is kind of a big stick for what we're trying to achieve: (configuring an LCD with settings from a file on SD card).
Why is it a big stick? It has a couple of significant advantages over your implementation:
No offense intended ;) Perhaps I should have said it was a much more powerful feature.
- It already exissts in mainline.
- It can set several environment variables at once (and also perform any other commands you might need on your system).
- It is based on text files which are easy to edit without need for new tools.
- It will verify that your file has been transmitted correctly.
Don't get me wrong, I'm a big fan of autoscr.
As I mentioned, the customer requesting the feature has a regulatory requirement any time __code__ changes. They have interpreted boot loader scripts as being executable, so they have to write checks if the script changes, but not if "data" changes. They interpret a file containing a variable as data.
Of course they'll need a code release to get there, ...
Our particular need is just for a single environment variable, so the update works pretty well. I started by updating our 'lcdpanel' U-Boot command to read from file, but this is much more useful.
I suggest you use autoscr instead.
I think I will reject your patch.
That's reasonable. I don't mind carrying the patch around for this customer, and you're the one preventing U-Boot from becoming bloated over time.
I appreciate all of your efforts.
Regards,
Eric