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

[lkcl]

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.

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

other areas are the memset before VM is set up, followed by memset *again* on.individual pages once created.  those are an hour each

another hour is spent on early device tree flat walking.

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.