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

[Ricardo Ribalda Delgado]

Hello Michal and Stefan

>> Hi Stefan
>
> You missed my name but ok.

Sorry I didn't mean it.

>
>>   First of all: Thanks for taking some time in reading the patch
>>
>>
>>> I looked at your patch.
>>> your xparameters contain space before tab
>>
>> Sorry :), BTW: do you know how to highlight this in vim?
>
> read Menon email

thanks, v2 of the patch takes care of all the coding style


> no you needn't - just you bsp - bsp take care about.
>

We can be thousands of hours discussing the same, your opinion is that
we need a bsp and mine is that it is not... My proposal is start a new
thread for this.

> 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

>>
>>> 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).

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

>>> 5. max flash sect - just choose one max value.
>>
>>    ok
>
> [snip]

Any SPI developer think that this is not a good idea? Any good max value?


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

> 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

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


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

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


>>      Thanks again for your comments
>>
>
> OK. I think we found a solution.
>

Again, Thanks for your comments, and sorry for not adding you in the
Hello line. At least I did also sent you the email directly to you and
stefan.


> I agree that your generic patch is better than adding next platform.
> If you can include changes which I report in previous email and resend, it will
> be great.
> Add only ml507 and small xparameters.h with values which are used not more.
>

The v2 patch is prepared and ready to go, I am waiting for some more
comments to include them. If you want I can sent it directly to you,
this patch is big and I don't want to disturb the list.


> Stefan: you are ppc440 custodian. I would like to see some comments from you.
>

ACK


-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/