[PATCH u-boot v2019.04-aspeed-openbmc] Revert "config/ast2500: Enable RAM devices"

[Joel Stanley]

On Wed, 9 Nov 2022 at 11:48, Zev Weiss <zweiss at equinix.com> wrote:
>
> On Tue, Oct 25, 2022 at 11:40:21PM PDT, Zev Weiss wrote:
> >This reverts commit ba91e9df1e16db0d209177148e864c65e58eb00f.
> >
> >CONFIG_RAM=y currently breaks DRAM initialization on ast2500; Aspeed
> >recommends against using it [0].
> >
> >[0] https://lore.kernel.org/openbmc/HK0PR06MB2834AE1581020A5B7CE191839C5B9@HK0PR06MB2834.apcprd06.prod.outlook.com/
> >
> >Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> >---
> >
> >Note that I'm not at all tied to this particular patch as the fix if
> >the interested parties can agree on better course of action; I'm
> >mostly just hoping to spur some further conversation given that
> >currently a vanilla OpenBMC build bricks my ast2500 systems in a way
> >that's not real easy to recover without a flash programmer.
> >
>
> Ping...I'm hoping to get e3c246d4i migrated to u-boot-aspeed-sdk soon
> (bearing in mind the end-of-year deadline suggested in Joel's email a
> few months ago [0]), but with this issue outstanding doing so will make
> any such systems self-bricking unless I hack around it with a bandaid
> kconfig fragment in a bbappend, which doesn't seem like a great fix
> since it's not really an e3c246d4i-specific problem.

I've merged this for now.

We should consider removing the C DRAM training, or re-working it to
match what the assembly does (IIRC it is different in structure
compared to the assembly. I don't know why).

>
>
> Thanks,
> Zev
>
> [0] https://lore.kernel.org/openbmc/CACPK8Xe4ijKWnURT4T9em2pUqifNdkZUfg0dd5osATYnqqutSw@mail.gmail.com/