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
