[U-Boot] [PATCH V7 0/4] Add disk support to orion5x and edminiv2
Rogan Dawes
rogan at dawes.za.net
Thu Aug 5 17:35:35 CEST 2010
On 2010/08/05 5:12 PM, Albert ARIBAUD wrote:
> Le 05/08/2010 16:28, Rogan Dawes a écrit :
>> On 2010/08/05 4:11 PM, Albert ARIBAUD wrote:
>>> Rogan, what other code do you think you'd be duplicating?
>>>
>>> Amicalement,
>>
>> In truth, I was really thinking only of the config files, not really the
>> code per se.
>>
>> I suppose that there is not really that much else that really is common.
>>
>> Rogan
>
> As for the configs, some u-boot boards do commonalize, see for instance
> include/configs/spear*.h. That makes sense because there is a board
> family, with a common HW design and common external components.
>
> For instance, the recently submitted patch for the kirkwood-based openrd
> family could probably commonalize since most of the OpenRD Base and
> OpenRD Client HW design is shared, and I assume Ultimate reuses it a lot
> too.
>
> In our case, the boards are from different manufacturers, so
> commonalization seems less obvious to me, except for MV88E1116 if both
> boards have it, but the config for it is a single define
> (CONFIG_RESET_PHY_R) which makes putting it in a common config header
> overkill (but commonalization of reset code would make sense though).
>
> Amicalement,
The DNS323 uses the Marvell 88E1111, but it is working with the same
config as yours, so I suppose they are compatible.
I was really thinking in terms of all the peripheral configs, the SATA,
USB, network, etc, which *should* be the same, since they are all based
on the same SoC.
While your edmini only uses a single SATA port, that could easily be
overcome by defining addresses for both in the board config, and just
#undef'ing it for those that do not use the second port. (It seems more
descriptive to have both ports defined in the same place, and then say
that the edmini doesn't use the second one).
I might just be being lazy, of course :-)
Rogan
P.S. Is there any attention being paid to the ARM defconfig cleanup
going on in the kernel, and thoughts of copying their approach?
More information about the U-Boot
mailing list