[lowrisc-dev] Porting U-Boot to lowRISC
mark.corbin at embecosm.com
Fri Sep 21 10:20:44 BST 2018
Many thanks for all the information - plenty for me to take a look at.
When are you expecting that the v0.6 release will be ready?
On 19/09/18 11:57, Dr Jonathan Kimmitt wrote:
> 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
> 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 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
> 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 ?? ()
> 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
> 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
> 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:
>> 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
>> 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