On 07/10/2012 03:12 PM, Marek Vasut wrote:
Dear Wolfgang Denk,
Dear Michal Simek,
In message<4ffc1ef8.9060...@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
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
