Wolfgang Denk wrote:
This is already streching the code to the limits, and the only reason you ever got this thrugh is that it's FSL specific code, you you have to deal yourself with this ugliness. I don;t think you will find good arguments to convince me adding such stuff into common code, though.
Well, I guess we'll just have to agree to disagree. I didn't think Mike's idea was a bad one, but if you don't like it, then I'll drop it.
Unfortunately, it only covers NOR flash. The new design covers NOR and NAND.
Well, your code does not really cover NOR flash. I think it covers only a small subset of the use cases, but horribly fails else.
For example, what happens when I just use "md" or "itest *addr" or similar trying to read NOR flash while the display is on?
The reason I make a big deal about saveenv is because I use an environment variable ("video-mode") to enable video support. Once the console is switched to the video display, the only way to switch it back to the serial port is to delete the environment variable, save the environment, and reboot.
If we had a command that switched the console back to the serial port, I wouldn't need any of this.
You _do_ have a broken hardware design, and if you cannot access NOR flash with display running, and vice versa, than just accept this fact.
Feel free to provide commands to switch mode, but don't lard the code with hooks here and there trying to fix what cannot be fixed.
Is there a way to switch the console
Well, you try again to fix just a single use-case, leaving all the others unsolved. It makes zero sense to fix "saveenv" while not fixing all other access modes to the same storage device.
Yes, it is a pain if you have to run something like
=> busmux flash;saveenv;busmux diu
Hmmm... that's not a bad idea. I'll think about it.
but the ugliness comes from the hardware design, so we have no reasoin to camouflage it. Let people see what is going on under the hood - if this is done in a clean way, you don't have to be ashamed.
LOL.