On 08/16/2012 07:27 PM, Joe Hershberger wrote:
Hi Michal,
On Thu, Aug 16, 2012 at 1:12 AM, Michal Simek <mon...@monstr.eu> wrote:
Hi Joe,
On 08/15/2012 07:31 PM, Joe Hershberger wrote:
Hi Michal,
I believe this is a fundamental misunderstanding of the Zynq architecture.
I don't think that this is not my fundamental misunderstanding.
With the microblaze and virtex ppc architecture you basically have an
FPGA that happens to have a processor in it. The Zynq architecture is
the opposite... an ARM system that happens to have an FPGA attached to
it.
We are working in this area for quite a long time to be convinced that
this is the best solution we can make. And even this is only one way how
to maintain this platform. Creating new u-boot board description for every
board or configuration is bad idea.
The different boards have plenty of hard IP and peripherals available
for all of the key interfaces that u-boot needs to be aware of.
Certainly there can be other peripherals added to the fabric and those
can be handles with device tree. Generally these boards are well
defined, unlike microblaze targets.
Zynq is not like any other ARM based board. There is still a lot of space
for configuring it and you need all the time any input from user even
if you use reference board. All reference boards contains a lot of
connectors
which started with FMC, pins, configurable options.
It is possible to add custom features in the fabric. I agree that it
is not reasonable to support many different possible things there.
That should be left to the user to customize.
ok.
On the other hand, I think it should be easy to use a given board
without first learning everything about it. Please consider each
board as though it has no fabric. What can be supported on the board
with what is connected to the MIO port? Can it run u-boot? Access
memory? Access Ethernet or USB? Boot Linux? In general, the answer
to all these is yes. However each board has different things
populated. Different RAM, different types of flash interfaces,
different Ethernet phys, etc.
For this purpose will be reference designs and BSPs for reference boards
and none has to spend time on these details.
It means one BSP for zc702 for EDK 14.2 one for 14.3, etc.
The same for the ZED board and others.
If you want to do it for your custom board then you have to compile
FSBL in SDK anyway and SDK will also generate DTS or currently what
we use in PetaLinux configuration file for u-boot because configuration
from DTS is not ready.
This will be well documented and there are just some steps which is quite
easy to do.
But I believe in near future when DM with OF is ready you will need
just DTS.
I have to also check what xilinx will be distributed with their reference
board but I expect that it will be the same as was with previous boards.
It means SD(COMPACT flash in past) card with several demos where one
will be Linux with DTS file.
If I get a Zed board and you get a ZC702 board, we should not each
have to write a DTS file and customize all the other config file
settings when those differences are known based on the board, just
because it is possible to further extend each of these boards beyond
their MIO capabilities.
I am not sure how did you write your DTS file but we and Xilinx
are using device-tree BSP in EDK to generate it.
It means you don't need to write it at all. We also have customization
extension to setup phy addresses for example. This extension is used in
PetaLinux and I expect will be also available in public git repository soon too.
You need to compile fsbl and in the same SDK menu you just select device-tree
BSP to generate it. Not sure if Xilinx included this to the latest EDK 14.2
but definitely they have this BSP here
http://git.xilinx.com/?p=device-tree.git;a=summary.
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
