[lowrisc-dev] Porting U-Boot to lowRISC

Dr Jonathan Kimmitt jrrk2 at cam.ac.uk
Wed Sep 19 11:57:41 BST 2018


Dear Mark,

(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 
and initialisation

sequence which was absent from the previous releases (a fixed sequence 
was used).

u-boot incorporates its own FSBL mode, but I was unable to get the DOS 
support working

properly. This could be due to lack of support in H/W for unaligned 
accesses.

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:

     https://github.com/lowRISC/lowrisc-quickstart.git

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 
upstream versions.

I don't have any instructions but if you have followed the quickstart 
flow at

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
     http://openocd.org/doc/doxygen/bugs.html
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 : [0] 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 
linux-4.18-patched/vmlinux

you then have the following command available

target remote :3333

Remote debugging using :3333
0x0000ffe000133f64 in ?? ()

layout asm
layout regs

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 
bare_metal/driver/lowrisc_memory_map.h
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
useful function.

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:
> Hello
>
> I've just produced a set of patches that add RISC-V 64-bit support to
> Buildroot[1]. 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
> upstream.
>
> 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
> bare_metal/examples/boot.c.
>
> Thanks
>
> Mark
>
> [1] https://buildroot.org/




More information about the lowrisc-dev mailing list