qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: Havard Skinnemoen <hskinnemoen@google.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"CS20 KFTing" <kfting@nuvoton.com>,
	"Cédric Le Goater" <clg@kaod.org>, qemu-arm <qemu-arm@nongnu.org>,
	"Joel Stanley" <joel@jms.id.au>,
	"IS20 Avi Fishman" <Avi.Fishman@nuvoton.com>
Subject: Re: [PATCH v5 01/11] hw/misc: Add NPCM7xx System Global Control Registers device model
Date: Thu, 9 Jul 2020 18:23:07 +0200	[thread overview]
Message-ID: <bd2972b0-0684-e379-6d66-16ceb62deade@amsat.org> (raw)
In-Reply-To: <CAFQmdRYx99PpWz6bftCvBR7=YRftD_WNex_A9aoDaeRg=4tsCw@mail.gmail.com>

On 7/9/20 8:43 AM, Havard Skinnemoen wrote:
> On Wed, Jul 8, 2020 at 11:04 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> On 7/9/20 2:35 AM, Havard Skinnemoen wrote:
>>> Implement a device model for the System Global Control Registers in the
>>> NPCM730 and NPCM750 BMC SoCs.
>>>
>>> This is primarily used to enable SMP boot (the boot ROM spins reading
>>> the SCRPAD register) and DDR memory initialization; other registers are
>>> best effort for now.
>>>
>>> The reset values of the MDLR and PWRON registers are determined by the
>>> SoC variant (730 vs 750) and board straps respectively.
>>>
>>> Reviewed-by: Joel Stanley <joel@jms.id.au>
>>> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>>> Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com>
>>> ---
[...]
>>> diff --git a/hw/misc/npcm7xx_gcr.c b/hw/misc/npcm7xx_gcr.c
>>> new file mode 100644
>>> index 0000000000..9934cd238d
>>> --- /dev/null
>>> +++ b/hw/misc/npcm7xx_gcr.c
>>> @@ -0,0 +1,226 @@
>>> +/*
>>> + * Nuvoton NPCM7xx System Global Control Registers.
>>> + *
>>> + * Copyright 2020 Google LLC
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License as published by the
>>> + * Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
>>> + * for more details.
>>> + */
>>> +
>>> +#include "qemu/osdep.h"
>>> +
>>> +#include "hw/misc/npcm7xx_gcr.h"
>>> +#include "hw/qdev-properties.h"
>>> +#include "migration/vmstate.h"
>>> +#include "qapi/error.h"
>>> +#include "qemu/log.h"
>>> +#include "qemu/module.h"
>>> +#include "qemu/units.h"
>>> +
>>> +#include "trace.h"
>>> +
>>> +static const uint32_t cold_reset_values[NPCM7XX_GCR_NR_REGS] = {
>>> +    [NPCM7XX_GCR_PDID]          = 0x04a92750,   /* Poleg A1 */
>>> +    [NPCM7XX_GCR_MISCPE]        = 0x0000ffff,
>>> +    [NPCM7XX_GCR_SPSWC]         = 0x00000003,
>>> +    [NPCM7XX_GCR_INTCR]         = 0x0000035e,
>>> +    [NPCM7XX_GCR_HIFCR]         = 0x0000004e,
>>> +    [NPCM7XX_GCR_INTCR2]        = (1U << 19),   /* DDR initialized */
>>> +    [NPCM7XX_GCR_RESSR]         = 0x80000000,
>>> +    [NPCM7XX_GCR_DSCNT]         = 0x000000c0,
>>> +    [NPCM7XX_GCR_DAVCLVLR]      = 0x5a00f3cf,
>>> +    [NPCM7XX_GCR_SCRPAD]        = 0x00000008,
>>> +    [NPCM7XX_GCR_USB1PHYCTL]    = 0x034730e4,
>>> +    [NPCM7XX_GCR_USB2PHYCTL]    = 0x034730e4,
>>> +};
>>> +
>>> +static uint64_t npcm7xx_gcr_read(void *opaque, hwaddr offset, unsigned size)
>>> +{
>>> +    uint32_t reg = offset / sizeof(uint32_t);
>>> +    NPCM7xxGCRState *s = opaque;
>>> +
>>> +    if (reg >= NPCM7XX_GCR_NR_REGS) {
>>> +        qemu_log_mask(LOG_GUEST_ERROR, "%s: offset 0x%04x out of range\n",
>>> +                      __func__, (unsigned int)offset);
>>
>> Maybe use HWADDR_PRIx instead of casting to int?
> 
> Will do, thanks!

Glad you are not annoyed by my review comments.

FYI your series quality is in my top-4 "adding new machine to QEMU".
I'd like to use it as example to follow.

I am slowly reviewing because this is not part of my work duties,
so I do that in my free time before/after work, which is why I can
barely do more that 2 per day, as I have to learn the SoC and
cross check documentation (or in this case, existing firmware code
since there is no public doc).

[...]
>>> +static void npcm7xx_gcr_realize(DeviceState *dev, Error **errp)
>>> +{
>>> +    NPCM7xxGCRState *s = NPCM7XX_GCR(dev);
>>> +    uint64_t dram_size;
>>> +    Error *err = NULL;
>>> +    Object *obj;
>>> +
>>> +    obj = object_property_get_link(OBJECT(dev), "dram-mr", &err);
>>> +    if (!obj) {
>>> +        error_setg(errp, "%s: required dram-mr link not found: %s",
>>> +                   __func__, error_get_pretty(err));
>>> +        return;
>>> +    }
>>> +    dram_size = memory_region_size(MEMORY_REGION(obj));
>>> +
>>> +    /* Power-on reset value */
>>> +    s->reset_intcr3 = 0x00001002;
>>> +
>>> +    /*
>>> +     * The GMMAP (Graphics Memory Map) field is used by u-boot to detect the
>>> +     * DRAM size, and is normally initialized by the boot block as part of DRAM
>>> +     * training. However, since we don't have a complete emulation of the
>>> +     * memory controller and try to make it look like it has already been
>>> +     * initialized, the boot block will skip this initialization, and we need
>>> +     * to make sure this field is set correctly up front.
>>> +     *
>>> +     * WARNING: some versions of u-boot only looks at bits 8 and 9, so 2 GiB or
>>> +     * more of DRAM will be interpreted as 128 MiB.
>>
>> I'd say u-boot is right in wrapping at 2GB, as more DRAM is
>> un-addressable.
> 
> Ah, maybe I shouldn't have said "or more". The bug is that if you
> specify _exactly_ 2GiB, u-boot will see 128 MiB.
> 
> But I agree more than 2GiB doesn't make sense, so I'll add a check for that.
> 
> Not sure if I agree that the check should be here. > 2 GiB is an
> addressing limitation, and the GCR module shouldn't really know what
> the SoC's address space looks like. The lower limit is because the GCR
> module can't encode anything less than 128 MiB.
> 
>>> +     *
>>> +     * https://github.com/Nuvoton-Israel/u-boot/blob/2aef993bd2aafeb5408dbaad0f3ce099ee40c4aa/board/nuvoton/poleg/poleg.c#L244
>>> +     */
>>> +    if (dram_size >= 2 * GiB) {
>>
>> See my comment in this series on the machine patch.
>>
>>> +        s->reset_intcr3 |= 4 << 8;
>>> +    } else if (dram_size >= 1 * GiB) {
>>> +        s->reset_intcr3 |= 3 << 8;
>>> +    } else if (dram_size >= 512 * MiB) {
>>> +        s->reset_intcr3 |= 2 << 8;
>>> +    } else if (dram_size >= 256 * MiB) {
>>> +        s->reset_intcr3 |= 1 << 8;
>>> +    } else if (dram_size >= 128 * MiB) {
>>> +        s->reset_intcr3 |= 0 << 8;

I think this can be simplified as:

         s->reset_intcr3 = (4 - clz32(dram_size)) << 8;

Which implicitly truncate to power of 2 (which is what this
block does, as you can have only 1 bank managed per this SGC).

But checking is_power_of_2(dram_size) and reporting an error
else, is probably even better.

>>> +    } else {
>>> +        error_setg(errp,
>>> +                   "npcm7xx_gcr: DRAM size %" PRIu64
>>> +                   " is too small (need 128 MiB minimum)",
>>> +                   dram_size);
>>
>> Ah, so you could add the same error for >2GB. Easier.
>>
>> Preferably using HWADDR_PRIx, and similar error for >2GB:
>> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


  reply	other threads:[~2020-07-09 16:24 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09  0:35 [PATCH v5 00/11] Add Nuvoton NPCM730/NPCM750 SoCs and two BMC machines Havard Skinnemoen
2020-07-09  0:35 ` [PATCH v5 01/11] hw/misc: Add NPCM7xx System Global Control Registers device model Havard Skinnemoen
2020-07-09  6:04   ` Philippe Mathieu-Daudé
2020-07-09  6:43     ` Havard Skinnemoen
2020-07-09 16:23       ` Philippe Mathieu-Daudé [this message]
2020-07-09 17:09         ` Havard Skinnemoen
2020-07-09 17:24           ` Philippe Mathieu-Daudé
2020-07-09 17:42             ` Havard Skinnemoen
2020-07-10  9:31               ` Philippe Mathieu-Daudé
2020-07-11  6:46                 ` Havard Skinnemoen
2020-07-12  5:49                   ` Havard Skinnemoen
2020-07-09  0:35 ` [PATCH v5 02/11] hw/misc: Add NPCM7xx Clock Controller " Havard Skinnemoen
2020-07-15  7:18   ` Philippe Mathieu-Daudé
2020-07-09  0:36 ` [PATCH v5 03/11] hw/timer: Add NPCM7xx Timer " Havard Skinnemoen
2020-07-15  7:25   ` Philippe Mathieu-Daudé
2020-07-15 23:04     ` Havard Skinnemoen
2020-07-16  8:04       ` Philippe Mathieu-Daudé
2020-07-09  0:36 ` [PATCH v5 04/11] hw/arm: Add NPCM730 and NPCM750 SoC models Havard Skinnemoen
2020-07-09  6:11   ` Philippe Mathieu-Daudé
2020-07-13 15:02   ` Cédric Le Goater
2020-07-14  0:44     ` Havard Skinnemoen
2020-07-14 11:37       ` Philippe Mathieu-Daudé
2020-07-14 16:01         ` Markus Armbruster
2020-07-14 17:11           ` Philippe Mathieu-Daudé
2020-07-15  1:03             ` Havard Skinnemoen
2020-07-15  9:35               ` Markus Armbruster
2020-07-09  0:36 ` [PATCH v5 05/11] hw/arm: Add two NPCM7xx-based machines Havard Skinnemoen
2020-07-09  5:57   ` Philippe Mathieu-Daudé
2020-07-09  6:09     ` Philippe Mathieu-Daudé
2020-07-09  0:36 ` [PATCH v5 06/11] hw/arm: Load -bios image as a boot ROM for npcm7xx Havard Skinnemoen
2020-07-13 17:50   ` Philippe Mathieu-Daudé
2020-07-09  0:36 ` [PATCH v5 07/11] hw/nvram: NPCM7xx OTP device model Havard Skinnemoen
2020-07-09  0:36 ` [PATCH v5 08/11] hw/mem: Stubbed out NPCM7xx Memory Controller model Havard Skinnemoen
2020-07-09 16:29   ` Philippe Mathieu-Daudé
2020-07-09  0:36 ` [PATCH v5 09/11] hw/ssi: NPCM7xx Flash Interface Unit device model Havard Skinnemoen
2020-07-09 17:00   ` Philippe Mathieu-Daudé
2020-07-12  5:42     ` Havard Skinnemoen
2020-07-13 17:38       ` Philippe Mathieu-Daudé
2020-07-14  2:39         ` Havard Skinnemoen
2020-07-09  0:36 ` [PATCH v5 10/11] hw/arm: Wire up BMC boot flash for npcm750-evb and quanta-gsj Havard Skinnemoen
2020-07-13 14:57   ` Cédric Le Goater
2020-07-13 17:59     ` Philippe Mathieu-Daudé
2020-07-13 18:02       ` Philippe Mathieu-Daudé
2020-07-14  2:56     ` Havard Skinnemoen
2020-07-14  9:16       ` Markus Armbruster
2020-07-14 11:29         ` Philippe Mathieu-Daudé
2020-07-14 16:21           ` Markus Armbruster
2020-07-14 17:16             ` Philippe Mathieu-Daudé
2020-07-15  9:00               ` Markus Armbruster
2020-07-15 10:57                 ` Philippe Mathieu-Daudé
2020-07-15 20:54                   ` Havard Skinnemoen
2020-07-16 20:56                     ` Havard Skinnemoen
2020-07-17  7:48                       ` Philippe Mathieu-Daudé
2020-07-17  8:03                         ` Thomas Huth
2020-07-17  8:27                           ` Philippe Mathieu-Daudé
2020-07-17  9:00                             ` Philippe Mathieu-Daudé
2020-07-17 19:18                               ` Havard Skinnemoen
2020-07-17 20:21                                 ` Cédric Le Goater
2020-07-17 20:52                                 ` Philippe Mathieu-Daudé
2020-07-17 20:57                                   ` Havard Skinnemoen
2020-07-20  7:58                               ` Markus Armbruster
2020-07-15  7:42       ` Cédric Le Goater
2020-07-15 21:19         ` Havard Skinnemoen
2020-07-09  0:36 ` [PATCH v5 11/11] docs/system: Add Nuvoton machine documentation Havard Skinnemoen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd2972b0-0684-e379-6d66-16ceb62deade@amsat.org \
    --to=f4bug@amsat.org \
    --cc=Avi.Fishman@nuvoton.com \
    --cc=clg@kaod.org \
    --cc=hskinnemoen@google.com \
    --cc=joel@jms.id.au \
    --cc=kfting@nuvoton.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).