qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Fix ast2500 protection register emulation


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH] Fix ast2500 protection register emulation
Date: Wed, 21 Feb 2018 15:27:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 02/20/2018 03:19 PM, Hugo Landau wrote:
>> I also gave it a test on an OpenBMC romulus image. Looks fine, but that's 
>> an old custom U-Boot. Which defconfig did you use for U-Boot HEAD ? 
> evb-ast2500_defconfig.

ok

> FYI, these changes are necessary, but not sufficient to get u-boot HEAD
> (or for that matter u-boot 2017.11, another version tested) running.
> 
> The other issues were
>   - the tests
>       while (!(readl(&regs->ecc_test_ctrl) & SDRAM_TEST_DONE));
>     and
>       while (!(readl(&info->regs->config) & SDRAM_CONF_CACHE_INIT_DONE));
>     which appear in various places in the u-boot source and which spin
>     forever. I made u-boot work by commenting these out in u-boot rather
>     than patching qemu, not familiar enough with qemu to implement this.

This patch :

  
https://github.com/openbmc/qemu/commit/4fb98fffd3115d8d3d0a16a1033f5335b5c0fd9b

fakes some more SDMC registers to let the SDRAM initialization run. you
might want to take a look at it.

Thanks,

C.  

>   - the call to reset_assert in ast2500_sdrammc_probe seems to actually
>     reset the machine rather than just initialize SDRAM as it is
>     apparently supposed to, leading to an infinite cycle of resets.
>     Couldn't quite figure out how it was supposed to work, so I
>     commented this out, since obviously qemu doesn't actually have SDRAM
>     initialization requirements.
> 
> The above changes plus this patch allowed u-boot to get to the u-boot
> CLI. Haven't tried booting anything with it yet though.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]