[U-Boot] [PATCH] ppc44x: RFC: Unification of virtex5 pp440 boards

[Michal Simek]

Hi Ricardo and Stefan,

>> Yes I agree with that we should keep one representative board with use generic
>> ppc platform but just one not more. I vote for xilinx ml507. It is enought.
>>
> 
> Avnet board is sold better (it is much cheaper) and ml507 is more
> "official"... Lets keep both. Stefan?

:-)

>>>> I see simplier way just add
>>>> #define BOARD_NAME "Avnet bla bla" or for xilinx too. And small change in puts.
>>>>
>>> If the user is using the generic design, he should see generic design
>>> in the prompt. Anyway, this is just a personal opinion, no big deal
>>> changing this
>> If user using generic design he has set standalone bsp in edk - no names. If he
>> wants to play with linux or u-boot just fill the name which he wants to see in
>> prompt. Bsp add U-BOOT to begin of command line. (for example U-BOOT-ML507>).
>> This is no problem.
>>
> 
> It depends if we continue with the bsp or not

bsp discuss is only about name not about style how to add new board or design.

>>>> XPAR_SPI_0_NUM_TRANSFER_BITS, XPAR_IIC_EEPROM_BASEADDR and XPAR_SPI_0_BASEADDR
>>>> are not used anywhere. And maybe some others. (LL_TEMAC driver is not in U-BOOT
>>>> -> I have full version with fifo and sgdma in my repo but LLTEMAC_0_BASEADDR is
>>>> not used in U-BOOT yet)
>>>>
>>> I use it on my design, that lines can be replaced. Anyway I have a
>>> working version of Xilinx SPI, I am waiting for some more tests to
>>> release it.
>> I understand. If you want I can check it on Microblaze too. But be aware that
>> this driver should not be based on xilinx files.
>>
> 
> It is not based on Xilinx files (not the same error again :) )
> Thanks. I receive an spi board next week, I have only tested through
> loopback. I don't want to release an untested code to the list. I sent
> it to you (and any other one that wants it).

ok.

>>>> Please compare both configs files - you can see changes which are board specific.
>>>> 1. point to proper xparameters.h
>>>> 2. ENV_OFFSET -> this could be generic
>>>    It  hardly depends on the .bit size and the flash size
>> Size of .bit is not a problem because you can alloc 2MB that should be enough
>> for every bitstream. For env size choose one sector. This is about layout of
>> flash (MTD). User can choose and I believe will choose his own layout which is
>> the best for him.
> 
> I hope it was that easy. Virtex FX50T bitstream is almost 3.5 MB and
> FX30T is 1.7...  Flash size is very valuable and must be well used.

you have more then 3,5MB of flash. IMHO size in xparam is better.

>>>    We have a generic board and specific boards that can overwrite the
>>> generic functions and add more functionality like custom link script,
>>> custom xparameters and custom boot, My opinion is that it is style
>>> oriented.
>> Yes. I understand reason why should user have create his own folder with his
>> design. It is important but again this is really user specific things. If he
>> want to see on every startup "Hello you are the best, my hero", he can change
>> what he wants but this is not for mainline u-boot.
> 
> What about external watchdogs, memory controller, Critial GPIOs?? Now
> there are not so many public boards with this, but we must be prepared
> to support them. And they need to be set up to start the system, they
> are the reason for having a bootloader.

if you will use non standard solution you need to directly in different way. If
you use common solution I will call it generic -> one ifdef.
GPIO -> you choose what gpio do -> distribution without design doesn't make
sense to me.

>> What is your simple board? Every board is simple if you know it. But you meant
>> simple design. That a big difference.
>>
>> Yes. commercial matter is important. We can add thousand of design in microblaze
>> or ppc405,ppc440 folders and Wolfgang could write that u-boot supports thousand
>> boards. But the real state will be different. And the same from Xilinx and Avnet
>> site but what will be better to support thousands board (or design) or just full
>> ppc440 based on xilinx fpga. What is bigger? And who choose what boards are the
>> most/sold. I don't have numbers.
> 
> Support explicitly thousands of boars and implicitly any ppc440 xilinx board

It is up to Stefan,

>> The next things which can comes in after 2 years. You are board maintainer for
>> ml507 and this board will be ancient but U-BOOT will contain this board and will
>> we move several years till someone just remove it. The same situation comes with
>> others board.
> 
> The m507 has no specific code in it: this is the real good thing.
> Their source code is in ppc440-generic, which is the only board that
> should be explicitly maintained. There is no code replication.

yes, just design specific things.

>> I haven't invented BSP style in EDK. You have to choose linux one if you want to
>> work with linux. I believe you are not lazy to choose different one.
> 
> I am lazy to install another BSP that maybe wont support my design.

:-) you are developer. You can develop.

> 
>> For example fdt bsp which I started with it (currently is maintained by Xilinx)
>> should be in EDK or maybe is. EDK is not standard and the things there are not
>> fully up to date. I will talked with people from Xilinx if is possible to and
>> which are their requirements for add u-boot bsp to EDK.
>>
> 
> If there is a u-boot bsp in EDK, I will be the first in using it, but
> until them I stay with linux2_6 bsp

:-)

>> This is different theme and I don't want to disturb people in u-boot mailing
>> list. This is only about name. It is up to Stefan which names are acceptable for
>> him.
>>
>>
> 
>> You are wrong. Xparameters.h is looooooong file where 98% of values are
>> unneeded. In Loong file with lot of information you lose everything. Maybe you
>> will be happy that you have looooong file and there is a lot of information but
>> the purpose of this file is...
>> Loong xparameters.h was unacceptable for linux-kernel in ppc branch and is in
>> EDK due to compatibility. FDT solved this.
> 
> But u-boot needs a .h Some days ago there was a discussion about this
> on the list.

I don't know. :-(

Michal