Dear Stefan,
In message 200906081937.02354.sr@denx.de you wrote:
- out_be32(&im->mddrc.lut_table4_alternate_upper,
CONFIG_SYS_MDDRCGRP_LUT4_AU);
- out_be32(&im->mddrc.lut_table4_alternate_lower,
CONFIG_SYS_MDDRCGRP_LUT4_AL);
Lines too long.
OK. Some is true for aria and mcp5121ads btw. But I'll change it in the next patch version.
If you argument that the too long lines are easier to read then the wrapped ones, I will not fight about this :-)
+phys_size_t initdram(int board_type) +{
- return fixed_sdram();
+}
Use auto-sizing?
You refer to using get_ram_size()? I'm no big fan of using this routine in a fixed environment (only one soldering possibility). But ok, I can change this too.
Yes, I stronlgy recommend to use this even on fixed configurations. Keep in mind that it includes a very fast yet pretty efficient memory test that will catch 95% of all RAM issues. It's a great help not only for the board bringup, but also for diabnosing problems in the field. If I could, I would like to make the use of get_ram_size() mandatory :-)
BTW, again this is the same code as in aria.
I know. It's on my list of things to iron out in this port.
How long does it to boot with such an environment in EEPROM?
Quite long. About 10 seconds to the U-Boot prompt.
He. And then try "setenv baudrate 115200 ; saveenv" and measure again.
Does your customer really want to release such a product to his customers? Other boards boot in a fraction of that time.
+#define CONFIG_OF_LIBFDT 1 +#define CONFIG_OF_BOARD_SETUP 1 +#define CONFIG_OF_SUPPORT_OLD_DEVICE_TREES 1
Do you really need this on a new board?
Probably not. Again this is just a copy from aria. I'll remove it in the next patch version.
Thanks for pointing out. I put it on my cleanup list, too.
Best regards,
Wolfgang Denk