[Libre-soc-dev] microwatt booting linux-5.7 under verilator
npiggin at gmail.com
Mon Jan 31 03:31:41 GMT 2022
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,
> full memory read/write snooping and full Signal tracing (gtkwave) is possible.
> the branch of microwatt HDL which is being used is here
> 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
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
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?
More information about the Libre-soc-dev