From: Havard Skinnemoen <hskinnemoen@google.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
qemu-arm <qemu-arm@nongnu.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"IS20 Avi Fishman" <Avi.Fishman@nuvoton.com>,
"CS20 KFTing" <kfting@nuvoton.com>,
"Joel Stanley" <joel@jms.id.au>,
"Cédric Le Goater" <clg@kaod.org>
Subject: Re: [PATCH v5 01/11] hw/misc: Add NPCM7xx System Global Control Registers device model
Date: Thu, 9 Jul 2020 10:42:06 -0700 [thread overview]
Message-ID: <CAFQmdRa3u_Sst0i6e2whoJcYau15gVQubhZHmm+z26SD8G8uCQ@mail.gmail.com> (raw)
In-Reply-To: <ee8bc620-6d58-98ef-1c53-a8687282af50@amsat.org>
On Thu, Jul 9, 2020 at 10:24 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 7/9/20 7:09 PM, Havard Skinnemoen wrote:
> > On Thu, Jul 9, 2020 at 9:23 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >> 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).
> >
> > Your feedback is super valuable, thanks a lot. I really appreciate it.
>
> OK I'll continue, but might not have time until next week.
> After I plan to test too.
OK, I'll try to post a v6 before the weekend, unless you prefer that I
hold off until you've reviewed the whole series.
> What would be useful is an acceptance test (see examples in
> tests/acceptance/), using the artefacts from the link you shared
> elsewhere:
> https://openpower.xyz/job/run-meta-ci/distro=ubuntu,label=builder,target=gsj/lastSuccessfulBuild/artifact/openbmc/build/tmp/deploy/images/gsj/
Yes, tests are definitely on my radar. I'm working on SPI flash
qtests. I haven't had much success with avocado yet, but I'll keep
trying (perhaps using docker to control the environment more tightly).
Since the 5.1 release is frozen now, I might post some followup
patches before this series is merged, e.g. tests, bootrom
submodule+blob, more peripherals, etc. Is it preferable to keep this
series frozen (modulo API updates) since you spent a lot of time
reviewing it, and post the new stuff separately, or is it better to
add new patches to the end of the series and resend the whole thing?
> But these are apparently not stable links (expire after 30 days?).
Sorry, I'm too ignorant about Jenkins to know. I'll see if I can
figure something out.
> >> [...]
> >>>>> +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).
> >
> > Good idea. I find this a little easier to understand though:
> >
> > #define NPCM7XX_GCR_MIN_DRAM_SIZE (128 * MiB)
> >
> > s->reset_intcr3 |= ctz64(dram_size / NPCM7XX_GCR_MIN_DRAM_SIZE) << 8;
>
> I like it, furthermore it will work with >4GB if this model is
> ever reused on an ARMv8-A SoC.
>
> >> But checking is_power_of_2(dram_size) and reporting an error
> >> else, is probably even better.
> >
> > OK, I'll add a check for this, and also explicit checks for too large
> > and too small. The former is currently redundant with the DRAM size
> > check I'm adding to npcm7xx_realize(), but I kind of like the idea of
> > checking for encoding limitations and addressing limitations
> > separately, as they may not necessarily stay the same forever.
> >
> >>>>> + } 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>
> >
next prev parent reply other threads:[~2020-07-09 17:43 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é
2020-07-09 17:09 ` Havard Skinnemoen
2020-07-09 17:24 ` Philippe Mathieu-Daudé
2020-07-09 17:42 ` Havard Skinnemoen [this message]
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=CAFQmdRa3u_Sst0i6e2whoJcYau15gVQubhZHmm+z26SD8G8uCQ@mail.gmail.com \
--to=hskinnemoen@google.com \
--cc=Avi.Fishman@nuvoton.com \
--cc=clg@kaod.org \
--cc=f4bug@amsat.org \
--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).