Hi John and Steve, >> The .dts is not board specific, it's design specific. > > Sure. I'm not sure how that changes where the .DTS files should be > stored. I will not change this handling with platform now. > I find it extremely helpful from a configuration management point of > view to cluster together all of the platform-specific code and data. I > also think it simplifies things for users, and that makes my life easier > in answering questions on the MicroBlaze list. ACK. I use platforms for testing too. >> In my opinion, >> this is not something that 'a vendor might maintain multiple versions >> of': instead it is in most cases simply fundamental to the FPGA design >> flow. > > Sure it is. Here's an ML505 design using the DVI video out. Here's one > using the LL_TEMAC in SGMII mode. Multiple designs, same board, all > will use the same board init but different DTS files. > > These could be thrown down in /boot along with every other tree, but > why? They have nothing in common with the other files down there, and > everything in common with the board/design-specific code. > > Am I missing something? yes. One board many designs that's all. >> In fact, in most cases, I'd like to make the .dts file part of >> the bitstream and not compiled into the kernel. > > Well, I've just run out of BRAM on a V5LX50T design so please don't ask > for more of it to store a DTC! :) Or do you mean to piggyback on the > tail of the configuration stream and read with some kind of JTAG user > code? snip >> Although powerpc has a bit more boot-time complexity than the microblaze >> does currently, I think it makes alot of sense to have some consistency >> here, and there is already a pattern to follow here which nicely >> orthogonalizes multiple .dts files for the same platform code. > > arch/powerpc/boot is building a bootloader, so maybe that's why .dts > files belong there. The bootloader is really the only thing that cares > about them as objects. Once the kernel starts, it's just dereferencing > a pointer that happens to point to a datastructure it understands (or > copying it as a blob before doing same). > > In fact, you could mount an argument that .dts files don't belong > anywhere near the MicroBlaze kernel, since our build process never > actually touches them. In fact. PowerPC has almost the same boot-time complexity as Microblaze has. Just use U-BOOT and you can see. You can handle with DTB, you can change everything there. I think it's good time for Xilinx to look at it. You will be surprised what is there. :-) I designed a startup part as complex can be. Passing three parameters to kernel direct everything. You can compile DTB to kernel for final products - only set one param to address in kernel. You can load DTB externally. You can use compiled in FS you can use special image with FS. (I haven't tested Initramfs). U-BOOT supports FIT where you can have many kernels, many fs with many DTB. All in one pack. :-) http://git.denx.de/?p=u-boot.git;a=tree;f=doc/uImage.FIT;h=b47619b84e4c1aa70911156af5aae6f52a5f8e1f;hb=HEAD Michal -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
