[lowrisc-dev] Porting U-Boot to lowRISC
Dr Jonathan Kimmitt
jrrk2 at cam.ac.uk
Wed Sep 19 11:57:41 BST 2018
(Caution to mailing list, this information concerns an unreleased tree
which subject to change)
A cut down version of u-boot will be used as the default SD-Card booter in
the refresh-v0.6 release. This incorporates a useful card recognition
sequence which was absent from the previous releases (a fixed sequence
u-boot incorporates its own FSBL mode, but I was unable to get the DOS
properly. This could be due to lack of support in H/W for unaligned
For what it's worth, my version is stored in
https://github.com/jrrk/u-boot-riscv.git on branch ariane
However there is very little that is ariane specific in there, just some
CSRs which are different.
This u-boot has not been tested on the forthcoming refresh-v0.6 release,
and is not a priority
because most of the configurability the u-boot supports such as
non-volatile environment, hw clock
support and USB devices is not available on the Nexys4DDR.
Our own version of buildroot, based on the firesim release, is available at
https://github.com/lowRISC/buildroot.git on branch refresh-v0.6
I am preparing some instructions for the refresh-v0.6 quickstart which
are available at:
This is a work in progress but I've already had some enquiries about it.
This is a binary release which
incorporates JTAG debugging via openocd. To get the actual patched
openocd you need to go to
https://github.com/lowRISC/riscv-tools on branch refresh-v0.6
The openocd.cfg that you were asking for is at the top level of that
repository. You need to use our version
of openocd because the IRLEN and USER jtag settings in the upstream
repository are incompatible with
Xilinx requirements. It would have been nice if someone had checked that
before freezing the debug spec
but you can't have everything. The other tools have not changed from the
I don't have any instructions but if you have followed the quickstart
https://www.cl.cam.ac.uk/~jrrk2/docs/GettingStarted/ (temporary location)
and compiled our version of openocd using buildocd.sh, then you and just
do openocd -f openocd.cfg
openocd -f openocd.cfg
Open On-Chip Debugger 0.10.0+dev-00165-gdc312f57 (2018-08-29-11:55)
Licensed under GNU GPL v2
For bug reports, read
adapter speed: 10000 kHz
Info : ftdi: if you experience problems at higher adapter clocks, try
the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x13631093 (mfg: 0x049
(Xilinx), part: 0x3631, ver: 0x1)
Info : dtmcontrol_idle=5, dmi_busy_delay=1, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=2, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=3, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=4, ac_busy_delay=0
Info : Disabling abstract command reads from CSRs.
Info : Disabling abstract command writes to CSRs.
Info :  Found 1 triggers
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=64, 1 triggers
Info : Listening on port 3333 for gdb connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
in another window, you can do riscv64-unknown-elf-gdb -tui
you then have the following command available
target remote :3333
Remote debugging using :3333
0x0000ffe000133f64 in ?? ()
At the moment the dissasembly and display is only amenable to machine
mode, I would suggest your
top priority task would be to get meaningful debugging working when
virtual memory is on. However
for debugging u-boot there is no problem as it runs always in machine mode.
It is not our policy to upstream patches before any silicon has been
made. This is because the maintenance
of such patches would restrict the freedom to innovate at the FPGA
stage, and place a burden on maintainers.
The default booter for refresh-v0.6 is bare_metal/examples/boot.c, but
this is pretty much a shell around the
relevant u-boot routines and bare metal ethernet server as appropriate.
This will be ROM code so it is important
that is minimised.
The BBL that comes with our quickstart repository is pretty much based
on Rocket with a colour logo and lowrisc.dts
is in that repository as well. It automatically gets attached to the
build of BBL. The built in Rocket DTB is pretty much ignored,
as we don't want the bother of declaring all our peripherals in Chisel.
You can get all the information about the memory map
from there as well. I'm not sure if our patches to BBL have any
hardwired addresses assumed before the DTB is loaded.
The Linux portion at least, is fully configured from the DTB.
The FSBL does not use DTB at all, it uses
If it was necessary to support multiple DTBs with a single FSBL, this
could be changed.
To address the main part of your question, is it a good idea to work on
u-boot as the future for lowRISC, we don't have
a working open-source QSPI nor-flash driver in Verilog at the moment,
for various reasons we are keen to move away from
the Xilinx IP that was part of the v0.3 release. You can see my initial
porting efforts in this direction on the spi_flash branch.
Once accepted that it does not fit in on-chip RAM, the only other option
is SD-Card, and since the existing booter can already
in principle choose from a variety of programs on SD-Card, the majority
of the u-boot functionality would not get used.
Of course, if there is a vast eco-system of RISCV hardware just waiting
for u-boot to take advantage of it, then the fact that the
Nexys4DDR can not use most of its capabilities would be irrelevant if it
is a suitable development platform. If u-boot had the
ability to manipulate device trees such that the Linux kernel could see
or be hidden from various hardware that might be a
PS The kc705 support that you mention below is a hangover, the new work
on kc705 is happening on the kc705_mii branch.
On 19/09/18 10:33, Mark Corbin wrote:
> I've just produced a set of patches that add RISC-V 64-bit support to
> Buildroot. This allows you to build a RISC-V toolchain, kernel and
> rootfs (currently for a QEMU virtual target). My next plan was to
> produce an image that would boot on the lowRISC using a Nexys4-DDR
> board. Having looked at the differences between the riscv-pk version of
> BBL and the lowRISC version of BBL, I decided that porting U-Boot to
> lowRISC would be a good place to start. Hopefully this would eventually
> provide some bootloader consistency between various target boards and
> would also provide a method of passing a device tree to a lowRISC kernel.
> I'd be interested in any work that has been done on this so far, and
> would be keen to try and produce a suitable set of patches for posting
> I have a few initial questions in this area:
> 1) Does anybody have a suitable openocd configuration file for the
> Nexys4-DDR board (and perhaps some instructions)? Ultimately I'd like to
> program U-Boot to the QSPI flash, but initially I could use openocd to
> download and run a copy in RAM.
> 2) Which files are used to generate the default boot.mem for the
> Nexys4-DDR? I thought that it might be bare_metal/examples/boot.c, but
> I'm not sure.
> 3) Where is the memory configuration done for the Nexys4-DDR? I can see
> memory configuration for the KC705 in kc705/examples/boot.c, but I can't
> find any equivalent for the Nexys4-DDR, and there is nothing in
>  https://buildroot.org/
More information about the lowrisc-dev