Re: microwatt booting linux-5.7 under verilator

From: Michael Ellerman <mpe@ellerman.id.au>
To: Nicholas Piggin <npiggin@gmail.com>,
	Libre-Soc General Development <libre-soc-dev@lists.libre-soc.org>,
	linuxppc-dev@lists.ozlabs.org,
	Luke Kenneth Casson Leighton <lkcl@lkcl.net>,
	lkcl <luke.leighton@gmail.com>,
	openpower-hdl-cores
	<openpower-hdl-cores@mailinglist.openpowerfoundation.org>
Subject: Re: microwatt booting linux-5.7 under verilator
Date: Tue, 01 Feb 2022 22:53:14 +1100	[thread overview]
Message-ID: <87o83qn6qd.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <1643696448.f3llnvzeyb.astroid@bobo.none>

Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from lkcl's message of January 31, 2022 2:19 pm:
>> 
>> On January 31, 2022 3:31:41 AM UTC, Nicholas Piggin <npiggin@gmail.com> wrote:
>>>Hi Luke,
>>>
>>>Interesting to read about the project, thanks for the post.
>> 
>> no problem. it's been i think 18 years since i last did linux kernel work.
>> 
>>>> i also had to fix a couple of things in the linux kernel source
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/joel/microwatt.git
>>>
>>>I think these have mostly (all?) been upstreamed now.
>> 
>> i believe so, although last i checked (6 months?) there was some of dts still to do. instructions online all tend to refer to joel or benh's tree(s)
>> 
>>>> this led me to add support for CONFIG_KERNEL_UNCOMPRESSED
>>>> and cut that time entirely, hence why you can see this in the console
>>>log:
>>>> 
>>>>     0x5b0e10 bytes of uncompressed data copied
>>>
>>>Interesting, it looks like your HAVE_KERNEL_UNCOMPRESSED support
>>>patch is pretty trivial. 
>> 
>> yeah i was really surprised, it was all there
>> 
>>> We should be able to upstream it pretty
>>>easily I think?
>> 
>> don't see why not.
>
> Okay then we should.
>
>> 
>> the next interesting thing which would save another hour when emulating HDL at this astoundingly-slow speed of sub-1000 instructions per second would be in-place execution: no memcpy, just jump.
>> 
>> i seem to recall this (inplace execution) being a standard option back in 2003 when i was doing xda-developers wince smartphone reverse-emgineering, although with it being 19 years ago i could be wrong
>
> 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).

If you build with CONFIG_RELOCATABLE=y and CONFIG_RELOCATABLE_TEST=y the
kernel will run wherever you load it (must be 64K aligned), without
copying itself down to zero first. That will save you a few cycles.

cheers