[Phishing Risk] [External] AST2500 u-boot breakage with CONFIG_RAM=y

[Dylan Hung]

Hi Zev, Zhang,

Aspeed recommends using "CONFIG_RAM=n" on AST2500 since platform.S is created by Aspeed.

> -----Original Message-----
> From: Zhang Jian [mailto:zhangjian.3032 at bytedance.com]
> Sent: Saturday, October 1, 2022 11:21 AM
> To: Zev Weiss <zev at bewilderbeest.net>
> Cc: openbmc at lists.ozlabs.org; Andrew Jeffery <andrew at aj.id.au>; Dylan
> Hung <dylan_hung at aspeedtech.com>; ChiaWei Wang
> <chiawei_wang at aspeedtech.com>; Ryan Chen
> <ryan_chen at aspeedtech.com>; Joel Stanley <joel at jms.id.au>
> Subject: Re: [Phishing Risk] [External] AST2500 u-boot breakage with
> CONFIG_RAM=y
> 
> Hi Zev,
> 
> I had some similar questions about this .
> 
> On Sat, Oct 1, 2022 at 5:09 AM Zev Weiss <zev at bewilderbeest.net> wrote:
> >
> > Hello u-boot/Aspeed folks,
> >
> > I recently set about getting e3c246d4i switched over to
> > u-boot-aspeed-sdk from the old u-boot branch, but after building and
> > installing it I ran into some odd misbehavior.
> >
> > It's not entirely consistent -- sometimes the kernel hand-off goes
> > alright but then the kernel's boot sequence hangs a few seconds in,
> Load the kernel is slow, will cause my 22's watchdog timeout.
> > sometimes it hangs before I get any kernel console output at all, and
> I disabled the watchdog, and always hang in the kernel.
> [    2.382046] ftgmac100 1e660000.ethernet: Read MAC address
> 2e:38:9e:24:b0:7c p
> [    2.389968] ftgmac100 1e660000.ethernet: Using NCSI interface
> [    2.397721] ftgmac100 1e660000.ethernet eth0: irq 20, mapped at
> (ptrval)
> [    2.405224] ftgmac100 1e680000.ethernet: Read MAC address
> d2:8a:d4:b8:26:da
> > sometimes I end up with the following error message from u-boot as it
> > loads the kernel FIT image:
> >
> >    fdt_find_or_add_subnode: chosen: FDT_ERR_BADSTRUCTURE
> >    ERROR: /chosen node create failed
> >     - must RESET the board to recover.
> >
> >    FDT creation failed! hanging...### ERROR ### Please RESET the board
> > ###
> >
> > Additionally, if I try to boot a FIT image loaded via TFTP I
> > consistently get checksum-mismatch errors on the kernel subimage
> > portion (though the exact same FIT image loaded from flash passes that
> check).
> >
> > I wasn't able to reproduce any misbehavior in qemu, unfortunately.
> >
> > I had previously tested the 2019.04 u-boot branch on this platform and
> > not hit any problems like this, so I started bisecting between the
> > version that had worked before and the current version, which landed
> > me on Joel's recent patch adding CONFIG_RAM=y to the evb-ast2500
> > defconfig (commit 0545d7325ff0cb1a77dc6f8007f74f415840fd90).  I
> > confirmed that setting CONFIG_RAM=n gets things working normally again.
> >
> Me too.
> 
> > Looking into the code that CONFIG_RAM=y enables, I added some debug
> > prints to arch/arm/mach-aspeed/ast2500/board_common.c and verified
> > that the dram_init() routine was setting gd->ram_size to the same
> > value in both cases.  However, I noticed there's also one instruction
> > in platform.S that's included when CONFIG_RAM is enabled [1].  My
> > recollection of ARM assembly is fairly rusty, but I believe that's
> > just an early return short-circuiting the rest of the initialization
> > code in that routine, perhaps with the intent that that work will get
> > taken care of by C code in the Aspeed RAM driver instead?  In any

Yes, that instruction is intended to bypass the dram initialization in platform.S

> > case, I experimented with leaving CONFIG_RAM=y but removing just that
> > instruction, and it seems to resolve the problems I was seeing -- so
> > if my interpretation does match the actual intent, it seems like
> > there's some discrepancy between the initialization done in the C code
> > and the assembly code, though I'm not sure what it might be.  For what

The C code will early return if bit6 of scu->vga_handshake[0] is set, which
means the dram initialization is actually done by platform.S, not the C code.

https://github.com/openbmc/u-boot/blob/8e834983d0a6b9265cee1674564b016565630883/drivers/ram/aspeed/sdram_ast2500.c#L422-L430
https://github.com/openbmc/u-boot/blob/8e834983d0a6b9265cee1674564b016565630883/drivers/ram/aspeed/sdram_ast2500.c#L461


> > it's worth, it did seem like the CONFIG_RAM=n build ran noticeably faster.
> >
> > Does anyone have any thoughts as to what might be going on, or tips on
> > how to go about debugging further?
> >
> > Thanks,
> > Zev
> >
> > [1]
> >
> https://github.com/openbmc/u-boot/blob/8e834983d0a6b9265cee1674564
> b016565630883/arch/arm/mach-aspeed/ast2500/platform.S#L663-L665
> >


--
Dylan