[PATCH u-boot v2019.04-aspeed-openbmc 1/1] ARM: dts: aspeed: add Quanta S6Q machine dts

[Zev Weiss]

On Thu, Apr 14, 2022 at 04:13:42AM PDT, Joel Stanley wrote:
>On Thu, 24 Mar 2022 at 20:55, Zev Weiss <zweiss at equinix.com> wrote:
>>
>> On Mon, Feb 28, 2022 at 07:13:44PM PST, George Hung (洪忠敬) wrote:
>> >>On Tue, 1 Mar 2022 at 01:23, George Hung <ghung.quanta at gmail.com>
>> >>wrote:
>> >>>
>> >>> Add build support for Quanta S6Q board equipped with
>> >>> AST2600 BMC SoC
>> >>
>> >>Hi George,
>> >>
>> >>Which configuration (defconfig) do you run your system with?
>> >
>> >Hi Joel,
>> >
>> >We use "evb-ast2600a1-spl_defconfig" for S6Q system.
>> >
>> >>
>> >>How different is this configuration from other platforms present in the tree?
>> >
>> >Not much difference:
>> >
>> >1. RGMII for mac2 and enable mdio3 function pins
>> >2. spi2 for BIOS flash
>> >3. mac delay for mac2/mac3 to prevent network abnormal after A/C
>> >4. I2C buses enabled according to S6Q platform
>
>I've merged your patch. Sorry for the delay.
>
>> >
>> >>
>> >>I ask as I wonder if we can get away with some common configs in u-boot,
>> >>without requiring every platform add their own dts.
>> >
>> >Does it mean you'd like to add the additional common dts for AST2600 ?
>>
>> Any further thoughts from anyone on the best way to add support for
>> platforms like this?  I've got a local patch adding a .dts for an
>> ast2400 system that differs from ast2400-evb.dts even less than the
>> above (just switching the console to a different UART and making a
>> similar pinctrl tweak for RGMII on mac1).  I was about to post it, but
>> then saw this thread, so I figured I'd hold off if there's likely to be
>> a Kconfig-based way of achieving that soon.
>
>I don't think there's a good way to solve this if the machine needs
>different options.
>
>One way to reduce the maintenance burden would be to include the evb
>dts in your dts, and make the required modifications.
>

Alright -- yeah, that's the approach I had taken, so it didn't seem too
terrible, just wasn't sure if we were trying to avoid adding more
per-board devicetrees entirely.  I'll post it shortly.


Thanks,
Zev