On Tue, Nov 20, 2007 at 07:16:08PM -0700, Grant Likely wrote:
Strictly speaking; firmware should be responsible for configuring the SoC (clocks, pinouts, etc). It makes it easier to add new boards if each one doesn't need it's own fixups.
I haven't checked the clock setup for lite5200 in u-boot yet, but it is not a complex change. And even if I do change it for the lite5200 in u-boot; this code probably won't go away in the kernel so as not to break compatibility with lite5200's with older u-boot firmware.
The point is that firmware should setup the CPU correctly at boot. It should not be Linux's responsibility. However, if there is *existing* firmware that needs to be supported; then I'll grudgingly accept hacks like this to keep the board bootable. If it is a new board, do it right the first time and do it in firmware (be it u-boot or otherwise)
In an ideal world, yes. Unfortunately, we have the situation that...
- There are old firmwares out there, so init code in Linux has to stay anyway, which means code duplication.
- For module-type boards, you don't even know which hardware the end user has attached to his module, so what do you want to initialize?
In general I really like your idea, but our experience is that, taken that there are these shortcommings, in reality the ARM model of transferring only a device number to the kernel and let the kernel do everything else works much better than all the fdt stuff and makes by far less problems in the long term.
Maybe we have an idea how to solve the problem in u-boot-v2. It already has loadable module support, so you can make generic board support for u-boot which does only minimum initialization, plus a loadable module for each "variant" (which is the generic board + a customer specific baseboard).
rsc