Timur Tabi wrote: > Well, I tried that a while back and it didn't work, but I can't remember > why. That was before I implemented a unified approach to Fman ucode > identification, so maybe it will work better now.
Ok, I remember now. The problem was that using the environment variable was messy. On some systems, we have two code sections: 1) loads the ucode into RAM early during boot, and 2) that same ucode is needed to when booting Linux. We used an environment variable to pass the address of the ucode from 1) to 2). That was deemed to be too fragile, so we switched to macros. I suppose if we get #2 to reload the ucode, that will make it work. Then #1 won't need to store the ucode permanently in memory. It's not a trivial fix, though. All of the existing code works on the assumption that the ucode is only located in one place. I still have a nagging feeling that I'm missing something, though. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
