Hi Wolfgang,
On 03/10/2013 12:59 AM, Wolfgang Denk wrote:
Dear Eric,
In message 1362873856-14785-1-git-send-email-eric.nelson@boundarydevices.com you wrote:
+Eric Nelson eric.nelson@boundarydevices.com
- nitrogen6dl i.MX6DL 1GB
- nitrogen6dl2g i.MX6DL 2GB
- nitrogen6q i.MX6Q/6D 1GB
- nitrogen6q2g i.MX6Q/6D 2GB
- nitrogen6s i.MX6S 512MB
- nitrogen6s1g i.MX6S 1GB
Why do we need different configurations for example for nitrogen6dl and nitrogen6dl2g? My understanding is that the difference is mainly the RAM size on the boards?
The difference is entirely the RAM size.
More specifically, it's the difference in the DDR density populated on the board.
In this case it should be possible to configure U-Boot for the maximum possible RAM size (2 GB here?), then have get_ram_size() detect the actual available amount, and then adjust settings as needed.
I'm not certain.
The JEDEC spec for the DDR devices we're using have quite different settings in a couple of areas. In particular, the tRFC value is quite different between densities.
They do appear to be minimums though, so we may be able to configure for the slowest value, run get_ram_size(), then reset that value once we determine whether the larger or smaller parts were populated on the board.
At least this is how U-Boot ius supposed to work.
It is a maintenance nightmare if each and every configuration requires a separate U-Boot image. We don't want to have this.
Well...
That throws a wrinkle into the whole patch set, since all of this code presumes that we're running from DDR and other calibration data was also gathered based on the actual parts used.
If this is a hard requirement, I don't see a solution that doesn't require the use of SPL, which will clearly take a while.
Please advise,
Eric