Re: [U-Boot-Users] uboot clock configuration on mpc5200 boards
On 11/20/07, Jon Smirl jonsmirl@gmail.com wrote:
On the Linux kernel the mpc52xx_setup_cpu() function used to do this fix up. Does uboot handle this for mpc5200 boards? If so, which version?
uboot is accessing these registers but it is not clear to me if the clocks are completely being set up.
The 5200lite code has been changed to this:
/*
- Fix clock configuration.
- Firmware is supposed to be responsible for this. If you are creating a
- new board port, do *NOT* duplicate this code. Fix your boot firmware
- to set it correctly in the first place
*/ static void __init lite5200_fix_clock_config(void) {
----8<----snip---->8----
}
Is uboot setting this up correct now that they kernel has been changed?
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)
Cheers, g.
On 11/20/07, Grant Likely grant.likely@secretlab.ca wrote:
On 11/20/07, Jon Smirl jonsmirl@gmail.com wrote:
On the Linux kernel the mpc52xx_setup_cpu() function used to do this fix up. Does uboot handle this for mpc5200 boards? If so, which version?
uboot is accessing these registers but it is not clear to me if the clocks are completely being set up.
The 5200lite code has been changed to this:
/*
- Fix clock configuration.
- Firmware is supposed to be responsible for this. If you are creating a
- new board port, do *NOT* duplicate this code. Fix your boot firmware
- to set it correctly in the first place
*/ static void __init lite5200_fix_clock_config(void) {
----8<----snip---->8----
}
Is uboot setting this up correct now that they kernel has been changed?
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.
Let me know when you sort it out in uboot. I'm using a Phytec pc030 and they've copied all of the 5200lite code. We're also building our own hardware which isn't ready yet.
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)
Cheers, g.
-- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely@secretlab.ca (403) 399-0195
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
In message 20071121070159.GI11448@pengutronix.de you wrote:
- 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?
...what has been specified in the device tree.
Best regards,
Wolfgang Denk
On Wed, Nov 21, 2007 at 12:21:20PM +0100, Wolfgang Denk wrote:
...what has been specified in the device tree.
How do you handle the fact that device trees do not cover the whole system, i.e. chips behind SPI and I2C busses?
Robert
In message 20071121121451.GU11448@pengutronix.de you wrote:
On Wed, Nov 21, 2007 at 12:21:20PM +0100, Wolfgang Denk wrote:
...what has been specified in the device tree.
How do you handle the fact that device trees do not cover the whole system, i.e. chips behind SPI and I2C busses?
The device tree is supposed to contain a complete hardware description, i. e. including devices attached to such busses.
[How do you handle this with an ARM machine ID? ;-) ]
Best regards,
Wolfgang Denk
On Wed, Nov 21, 2007 at 02:00:42PM +0100, Wolfgang Denk wrote:
How do you handle the fact that device trees do not cover the whole system, i.e. chips behind SPI and I2C busses?
The device tree is supposed to contain a complete hardware description, i. e. including devices attached to such busses.
Yes, it is supposed to, but reality is different. Ok, so we have to double-code everything until the world has achieved perfectionism.
[How do you handle this with an ARM machine ID? ;-) ]
Well, we don't have to. Linux has a driver model which handles all this once you know the machine. No need to duplicate everything. Redundancy is generally a bad thing.
Robert
participants (4)
-
Grant Likely -
Jon Smirl -
Robert Schwebel -
Wolfgang Denk