[Libre-soc-dev] microwatt booting linux-5.7 under verilator

[Nicholas Piggin]

Excerpts from lkcl's message of January 31, 2022 2:19 pm:
> 
> 
> On January 31, 2022 3:31:41 AM UTC, Nicholas Piggin <npiggin at 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).

> 
> 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).

> 
> another hour is spent on early device tree flat walking.

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.

Thanks,
Nick

> 
> one very big one (90+ mins) is the sysfs binary tree walk.  i'm sure even just saving the last node in a 1-entry cache would improve time there, or, better, a 4-entry cache (one per level)
> 
> although it sounds weird talking in a timeframe that is literally 100,000 times slower than what anyone else is used to, if improved it results in dramatic reduction in boot times for embedded IoT e.g BMC systems.
> 
>>> however in the interim, the attached patch suffices by manually
>>> altering the clock in microwatt.dts to match that of the SYSCON
>>> parameter.
>>
>>There is a dt_fixup_clock() that's used by a few platforms. Can we
>>read that parameter say in linux/arch/powerpc/boot/microwatt.c
>>platform_init() and fix it up there?
>>
>>How do you even read the SYSCON parameter for frequency?
> 
> SYSCON is just a term for a memory-mapped wishbone ROM which contains a crude easily-decoded binary form of devicetree.
> 
> when you read 0xc0001000 (say) its contents tell you the clock speed.
> 
> at 0xc0001008 is the number of UARTs.
> 0xc0001010 contains the UART0 speed or well you can see the real contents syscon.vhdl
> 
> it is _real_ basic but contains everything that
> a cold-start BIOS needs to know, such as "do i even have DRAM, do i have an SPI Flash i can read a second
> stage bootloader from" etc etc
> 
> https://github.com/antonblanchard/microwatt/blob/master/syscon.vhdl
> 
> Paul said it was always planned to do reading of these params, the entries in devicetree are a temporary hack.
> 
> l.
>