Hi John and Steve,

quoted text
>> 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.

quoted text
> 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.

quoted text
>> 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.

quoted text
>>   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

quoted text
>> 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=b47619b84e4c1aa70911156af5a...

Michal
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/