[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Michal Simek <monstr@monstr.eu>]

On 11/13/2013 03:39 PM, Chin Liang See wrote:
> On Tue, 2013-11-12 at 16:17 +0100, Michal Simek wrote:
>> On 11/12/2013 03:46 PM, Chin Liang See wrote:
>>> Hi all,
>>>
>>> On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote:
>>>> On 11/12/2013 10:56 AM, Detlev Zundel wrote:
>>>>> Hi Michal,
>>>>>
>>>>>> On 11/11/2013 09:33 PM, Tom Rini wrote:
>>>>>>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
>>>>>>>
>>>>>>>> Altera Cyclone 5 board is very different board (big, rectangular,
>>>>>>>> expensive) than EBV Socrates (small, circular, cheap) board. Different
>>>>>>>> parts are used there, too, but same configuration of u-boot works on
>>>>>>>> both. Nevertheless, printing wrong name confuses users.
>>>>>>>>
>>>>>>>> Therefore this splits the configuration so that u-boot knows they are
>>>>>>>> different. So far it is only used for correcting the puts, but there
>>>>>>>> may be other uses in future.
>>>>>>>>
>>>>>>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>>>>>>>
>>>>>>> Is there any way at run time to tell which board we are on?
>>>>>>
>>>>>> Why do you care about board name in general?
>>>>>
>>>>> We care for board names for a very long time in U-Boot and I'd like to
>>>>> keep this.  I actually expect a sensible board name on any platform that
>>>>> I touch.  The board name is an important extra information additional to
>>>>> the SoC name.  So the question is the other way round - since when do we
>>>>> _not_ care about board names?
>>>>
>>>> There could be i2c memory on board where you can find out this information but that's
>>>> problematic if it is empty or you want to use this i2c for something else.
>>>> For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design
>>>> (if user is smart enough board name is the part of hw design name).
>>>> For zynq/socfpga sensible solution is probably to load this name for DTS.
>>>>
>>>
>>> Currently, the SOCFPGA SPL is customized through a set of handoff files
>>> which located at board folders. These handoff files are generated by
>>> tools based on board and user design in FPGA. With that, not much
>>> decision being made during run time based on the board. With this
>>> handoff and tools approach, it will shield off the complexity of
>>> hardware configuration and errors (if user change it manually without
>>> tools help). Thanks
>>
>> Which nice copy of our approach. :-)
> 
> Hmmm... is it true? This approach being used since few years back at
> NIOS soft processor. Besides that, we are utilizing the SPL framework
> for our second stage boot loader. I believe you guys are not using SPL
> right? It seems you guys would need tools to generate and even build you
> guys own version of boot loader. It creates high dependency for user to
> your tools. 

Interesting discussion. :-)
I believe we will use SPL at some point in future for Microblaze
just because of easier maintenance . But will see.

I don't understand your point regarding to tool dependency. For DTSes
I believe you are also generating this structure from design tools
or you can write it by hand.
We are also generating U-boot configuration but if someone wants to write
it by hand they can.

> For our solution, customer can just grab the code from git and build it
> using the normal U-Boot way (if they don't want to use the tools). With
> the SPL also, we are taking advantage of open source community power to
> make our second stage boot loader more powerful and user friendly to
> user. Our user can grab any drivers or leverage the supports from the
> open community too. I believe that is the power of open source :) 

We have the same for Microblaze and Zynq.

Cheers,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131113/315f0a8f/attachment.pgp>