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

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

[Zev Weiss]

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

 configs/evb-ast2500_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
index d2a4e835dd12..b83c315e5057 100644
--- a/configs/evb-ast2500_defconfig
+++ b/configs/evb-ast2500_defconfig
@@ -64,7 +64,6 @@ CONFIG_PHY_GIGE=y
 CONFIG_FTGMAC100=y
 CONFIG_PHY=y
 CONFIG_PINCTRL=y
-CONFIG_RAM=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
-- 
2.38.1

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

[Zev Weiss]

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


Thanks,
Zev

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

Re: [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@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@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/