qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH 5/6] hw/arm: Add NPCM730 and NPCM750 SoC models


From: Cédric Le Goater
Subject: Re: [PATCH 5/6] hw/arm: Add NPCM730 and NPCM750 SoC models
Date: Thu, 11 Jun 2020 08:12:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 6/10/20 1:06 AM, Havard Skinnemoen wrote:
> On Tue, Jun 9, 2020 at 12:24 AM Cédric Le Goater <clg@kaod.org 
> <mailto:clg@kaod.org>> wrote:
> 
>     On 5/21/20 9:21 PM, Havard Skinnemoen wrote:
>     > +void npcm7xx_write_secondary_boot(ARMCPU *cpu, const struct 
> arm_boot_info *info)
>     > +{
>     > +    /*
>     > +     * The default smpboot stub halts the secondary CPU with a 'wfi'
>     > +     * instruction, but the arch/arm/mach-npcm/platsmp.c in the Linux 
> kernel
>     > +     * does not send an IPI to wake it up, so the second CPU fails to 
> boot. So
>     > +     * we need to provide our own smpboot stub that can not use 'wfi', 
> it has
>     > +     * to spin the secondary CPU until the first CPU writes to the 
> SCRPAD reg.
>     > +     */
>     > +    uint32_t smpboot[] = {
> 
>     static const uint32 ?
> 
> 
> I think that would be unsafe due to the byte swapping, but I'll do it if we 
> can get rid of that somehow.
>  
> 
> 
>     > +        0xe59f2018,     /* ldr r2, bootreg_addr */
>     > +        0xe3a00000,     /* mov r0, #0 */
>     > +        0xe5820000,     /* str r0, [r2] */
>     > +        0xe320f002,     /* wfe */
>     > +        0xe5921000,     /* ldr r1, [r2] */
>     > +        0xe1110001,     /* tst r1, r1 */
>     > +        0x0afffffb,     /* beq <wfe> */
>     > +        0xe12fff11,     /* bx r1 */
>     > +        NPCM7XX_SMP_BOOTREG_ADDR,
>     > +    };
>     > +    int i;
>     > +
>     > +    for (i = 0; i < ARRAY_SIZE(smpboot); i++) {
>     > +        smpboot[i] = tswap32(smpboot[i]);
> 
>     ah ! why do we need to swap the instructions ?
> 
> 
> I probably stole this from 
> https://elixir.bootlin.com/qemu/latest/source/hw/arm/exynos4210.c#L134 
> although there are several other examples of this pattern.

Some don't some do. This is a bit confusing. 

Peter, should we fix the boards not doing the tswap in the secondary 
bootloader ? 

I still have access to a PP64 BE host to test.

Thanks, 

C.



reply via email to

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