On 8/14/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote: > > > BTW: I'm currently hacking away to see if I can get a > > microblaze system > > booting > > using a flat device tree... I haven't decided if it's worth it to go > > that > > route in the end yet, but... > > > > Steve > > I've managed to get the first step working: a microblaze system > advertising of_devices in 2.6 using a flat device tree. The next task > is to > reimplement probe() for a driver or two (probably the xilinx_emac driver > first). My plan is to have the driver advertise both through > of_platform_bus, and > through the regular platform bus, and have a config option that either > advertises > the devices through of and links in the device tree, or using the > exising > platform_device mechanism.
That's fantastic. Yes, I think that is the right approach to have both platform_bus and of_platform bus bindings in the drivers. > > Grant: Does this make sense (in terms of dealing with drivers) with > your plans for > moving Virtex platforms to arch/powerpc? I'd like to avoid duplicating > work on the > drivers, if possible. Absolutely > > Is there a concensus on how microblaze systems should get booted? > Currently, > I'm linking the device tree directly into the kernel itself, loading the > whole > mess using SystemAce and the start address jumps directly into the > kernel, which > is quite a bit different than the way powerpc works. It's certainly > simpler: > maybe too simple. At the same time, replicating > the complexity of arch/powerpc with separate boot code may or may not be > worth it... > Any thoughts? It is a good starting point, and I think it is important that this remain an option (ie. for boards without a bootloader). However, it is a really good idea to support the notion of passing in a device tree from a bootloader (u-boot). As Michal mentioned, u-boot already has the code to support this, and u-boot is able to update the device tree directly. The key feature here is being able to support multiple FPGA designs from a single kernel image because the device tree gives us some level of abstraction on the hardware design. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded