On 07/10/2012 03:12 PM, Marek Vasut wrote:
Dear Wolfgang Denk,
Dear Michal Simek,
In message4FFC1EF8.9060705@monstr.eu you wrote:
The hardest part I have identify on microblaze was about u-boot variables. Because based on information from device-tree you can choose where variables should be stored and also this memory should be accessible before u-boot try to read variables. It mean in very early state.
Device initialization before relocation is already hard enough;
+1
resources are very limited then.
And we'll be introducing the early mallocator. This is where MPC85x will blow my mind :) (I'm repeating myself here, but it might help getting others unaware of the DM work better in line).
You will add the additional need to have the FDT library available then, too. Not to mention that you need to load the DT blob, too.
DT blob can be read from ROM if that was the problem. The DT library and parser might be an issue.
This will be a lot of added complexity.
And therefore slowing down the boot. But I believe it can be optimized to leverage this to some point. Though I'm not quite sure how much. This is worthy investigation.
Michal, can you try investigating how will the DT probing intertwine with the DM?
I have read your documentation and there are some things I would like to discuss.
UDM-design.txt
How do you want to distinguish between early drivers(console/memory) and common drivers?
struct driver: - for device-tree support there must be any pointer to matching table defined in every device driver.
- struct driver *cores[array] - can you please clear this usage? For example for any device on spi/i2c bus. What cores will depends on it? All SPI/I2C devices/device-drivers, just one, which one? Isn't it better to do it by priorities I mentioned above?
struct driver_info - Where do you want to fill the platform_data? Because for current u-boot configuration style this will be setup statically and for device-tree dynamically.
probe function require struct instance as parameter and how is it passed that platform data from struct driver_info which probably contains information required for probing - like address and other parameters required for configuration.
For device-tree all these options should be selected at run time. It means remove all ifdefs from drivers which of course increase u-boot binary size.
UDM-cores.txt about driver cores initialization at runtime. Do you need to initialized all driver cores at early-init stage? Or just that crucial one?
I am missing how you want to pass driver configuration data(addresses, settings) to the driver. I expect that this must be done out of device drivers.
Thanks, Michal