Re: microwatt booting linux-5.7 under verilator

From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: openpower-hdl-cores
	<openpower-hdl-cores@mailinglist.openpowerfoundation.org>,
	Libre-Soc General Development <libre-soc-dev@lists.libre-soc.org>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: microwatt booting linux-5.7 under verilator
Date: Tue, 1 Feb 2022 09:52:53 +0000	[thread overview]
Message-ID: <CAPweEDzwFK6zRxu5dXMDd_bqX=WTRQ97s9GHjJPW5Uu=Hc0qLQ@mail.gmail.com> (raw)
In-Reply-To: <1643696448.f3llnvzeyb.astroid@bobo.none>

On Tue, Feb 1, 2022 at 6:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:

> Not sure of the details on that. Is it memcpy()ing out of ROM or RAM to
> RAM? Is this in the arch boot code? (I don't know very well).

RAM to RAM.  arch/powerpc/boot/main.c:

    if (uncompressed_image) {
        memcpy(addr, vmlinuz_addr + ei.elfoffset, ei.loadsize);
        printf("0x%lx bytes of uncompressed data copied\n\r",
               ei.loadsize);
        goto out;
    }

in some systems those would be two different types of RAM,
(one would be on-board SRAM, the target would be DRAM
which had previously been initialised by the previous chain-boot
loader e.g. u-boot)

[in other circumstances, the source location might be addressable
SPI NOR flash, which would be slower, expensive, and therefore
compression is plain common sense, in which case it's out of
scope for this discussion.]

in the case of the simulation - and also in the case of the
WinCE Smartphone hand-held reverse-engineering using
GNUHARET.EXE (similar to LOADLIN.EXE if anyone remembers
that) - the uncompressed initramfs are both in the same
RAM, so the memcpy is completely redundant.

the only good reason for the memcpy would be to ensure
that the start location is at a known-fixed offset, and of course
that can be arranged in advance by the simulator.  even if
it has to be at 0x0000_0000_0000_0000 that can be arranged
by moving the cold-boot loader to an alternative hard-reset
start address and telling the simulated-core to start from there.

> >
> > other areas are the memset before VM is set up, followed by memset *again* on.individual pages once created.  those are an hour each
>
> Seems like we could should avoid the duplication and maybe be able to
> add an option to skip zeroing (I thought there was one, maybe thinking
> of something else).

it makes sense for security reasons (on real hardware) - a simulation
not so much, it's guaranteed to be all-zeros at startup.

> Are you using optimize for size? That can result in much slower code in
> some places. In skiboot we compile some of the string.h library code
> with -O2 for example.

interesting - no, this is default options.  have to be careful not to
introduce any VSX instructions (the core doesn't have them).

   CROSS_COMPILE="ccache powerpc64le-linux-gnu-" \
   ARCH=powerpc \
   make -j16 O=microwatt

l.