[U-Boot] Early I2C bus availability
Hi,
We're contemplating a new embedded design based on the MPC8641. This design is going to have the processor potentially running at two different clock frequencies and therefore (or so we're told by Freescale) the memory will need to run at different clock rates (same physical memory, but configured to run at different clock speed by uboot). All of this needs to be determined by jumpers (GPIO?) and then uboot needs to bring-up the memory using this different clock rate. All of this needs to happen before the memory is 'up', so early in the uboot init process.
Presuming all of that is possible, the problem becomes how to read the jumpers (GPIO) to get the configuration information to tell uboot what speed this memory should be run at. We are not going to have access to any GPIO directly located on the MPC8641. We are considering whether we can put a GPIO device on the I2C bus and have it read by the processor early in the uboot init process to get the information we need. My question is whether uboot will have enough resources early in the init process to do this?
If I am going about this totally the wrong way and there is a better approach please steer me in the right direction please.
Regards, Brent Bartson
Hi,
We're contemplating a new embedded design based on the MPC8641. This design is going to have the processor potentially running at two different clock frequencies and therefore (or so we're told by Freescale) the memory will need to run at different clock rates (same physical memory, but configured to run at different clock speed by uboot). All of this needs to be determined by jumpers (GPIO?) and then uboot needs to bring-up the memory using this different clock rate. All of this needs to happen before the memory is 'up', so early in the uboot init process.
Presuming all of that is possible, the problem becomes how to read the jumpers (GPIO) to get the configuration information to tell uboot what speed this memory should be run at. We are not going to have access to any GPIO directly located on the MPC8641. We are considering whether we can put a GPIO device on the I2C bus and have it read by the processor early in the uboot init process to get the information we need. My question is whether uboot will have enough resources early in the init process to do this?
Sure, just think about how DRAM is setup in many cases. First SPD data is read from an I2C EEPROM, then the DRAM controller is setup.
I read GPIO devices on the I2C bus very early too, it is no problem.
Jocke
Dear Brent Bartson,
In message 83A42A417FD59E48917448F8390945B70BC0FD@Exchange1.qvm.local you wrote:
We're contemplating a new embedded design based on the MPC8641. This design is going to have the processor potentially running at two different clock frequencies and therefore (or so we're told by Freescale) the memory will need to run at different clock rates (same physical memory, but configured to run at different clock speed by
OK. This is not an uncommon requirement.
uboot). All of this needs to be determined by jumpers (GPIO?) and
Why? You could use an environment variable as well - this allows to change the settings on the fly (ok, requireing a reboot, but at least without physical access to the hardware).
then uboot needs to bring-up the memory using this different clock rate. All of this needs to happen before the memory is 'up', so early in the uboot init process.
To be a bit more precise, replace "memory" with "RAM". And "early in the init process" just means "before relocation to RAM".
Presuming all of that is possible, the problem becomes how to read the jumpers (GPIO) to get the configuration information to tell uboot what speed this memory should be run at. We are not going to have access to any GPIO directly located on the MPC8641. We are
If you use GPIOs (why would you want to do that?), then why would you not have access to these?
considering whether we can put a GPIO device on the I2C bus and have it read by the processor early in the uboot init process to get the information we need. My question is whether uboot will have enough resources early in the init process to do this?
Yes, this can be done. There is virtually no limit to making things unneccesarily complicated.
If I am going about this totally the wrong way and there is a better approach please steer me in the right direction please.
Just encode the setting in an environment variable. See for example the "cpuclk" handling for some MPC8xx systems (arch/powerpc/cpu/mpc8xx/speed.c etc.)
Best regards,
Wolfgang Denk
participants (3)
-
Brent Bartson -
Joakim Tjernlund -
Wolfgang Denk