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

[Nicholas Piggin]

Hi Luke,

Interesting to read about the project, thanks for the post.

Excerpts from Luke Kenneth Casson Leighton's message of January 3, 2022 10:45 am:
> i am pleased to be able to announce the successful booting of microwatt-5.7
> linux buildroot... under a veriilator simulation of the microwatt VHDL.
> from a hardware development and research perspective this is highly
> significant because unlike the FPGA boot which was previously reported,
> https://shenki.github.io/boot-linux-on-microwatt/
> full memory read/write snooping and full Signal tracing (gtkwave) is possible.
> 
> https://ftp.libre-soc.org/microwatt-linux-5.7-verilator-boot-buildroot.txt
> 
> the branch of microwatt HDL which is being used is here
> https://git.libre-soc.org/?p=microwatt.git;a=shortlog;h=refs/heads/verilator_trace
> 
> some minor strategic changes to microwatt HDL were required, including
> adding a new SYSCON parameter to specify a BRAM chain-boot address,
> and also it was necessary to turn sdram_init into a stand-alone "mini-BIOS"
> which performed the role of early-initialising the 16550 uart followed by
> chain-loading to the BRAM chain-boot memory location, at which the linux
> 5.7 dtbImage.microwatt had been loaded (0x600000).
> 
> microwatt-verilator.cpp itself needed some changes to add support for
> emulation in c++ of 512 mbyte of "Block" RAM.  the interface for BRAM
> (aka SRAM) was far simpler than attempting to emulate DRAM, and
> also meant that much of the mini-BIOS could be entirely cut.
> 
> i also had to  further modify microwatt-verilator.cpp to allow it to load
> from files directly into memory, at run-time.  this means it is possible
> to execute hello_world.bin, zephyr.bin, micropython.bin, dtbImage-microwatt
> all without recompiling the verilator binary.
> 
> (not that you want to try compiling a 6 MB binary into VHDL like i did:
> it resulted in the creation of a 512 MB verilog file which, at 60 GB resident
> RAM by verilator attempting to compile that to c++, i decided that mayyybe
> doing that at runtime was a better approach?)
> 
> 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.

> first attempts to boot a compressed image were quite hilarious: a
> quick back-of-the-envelope calculation by examining the rate at which
> LD/STs were being generated showed that the GZIP decompression
> would complete maybe some time in about 1 hour of real-world time.
> 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. We should be able to upstream it pretty
easily I think?

> secondly, the microwatt Makefile assumes that verilator clock rate
> runs at 50 mhz, where the microwatt.dts file says 100 mhz for both
> the UART clock as well as the system clock.  it would be really nice
> to have microwatt-linux read the SYSCON parameter for the
> clock rate, and for that to be dynamically inserted into the dtb.
> 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?

Thanks,
Nick