Thread (9 messages) 9 messages, 6 authors, 2022-03-12

Re: microwatt booting linux-5.7 under verilator

From: Christophe Leroy <hidden>
Date: 2022-03-12 07:46:36


Le 03/01/2022 à 01:45, Luke Kenneth Casson Leighton a écrit :
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

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

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.
I'm not sure whether you expect this attached patch to me merged in 
mainline. If so, could you re-submit as a proper patch ?

Thanks
Christophe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help