How long does it take to boot Linux?

[hylee17]

"Load boot.bin into memory" I have stopped at the state. [nexys4_ddr fpga board]

plz... help me

step 1. download pre-built fpga.bit and boot.bin [v0.3] -> Downloading another version is the same....

step 2. I put fpga.bit and boot.bin on my sdcard

step 3. open the serial terminal

step 4. JP1[USB/SD] Setting and power On

but, don't load a boot.bin... and don't booting linux

[jrrk]

There are two jumpers to set, consult the nexys documentation.

It should take less than a minute for the green ‘done’ light to come on.

Sent from my iPhone

On 28 Oct 2017, at 08:18, hylee17 notifications@github.com wrote:

"Load boot.bin into memory" I have stopped at the state. [nexys4_ddr fpga board]

plz... help me

step 1. download preinstalled fpga.bit and boot.bin [v0.3] -> Downloading another version is the same....

step 2. I put fpga.bit and boot.bin on my sdcard

step 3. open the serial terminal

step 4. JP1[USB/SD] Setting and power On

but, don't load a boot.bin... and don't booting linux

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[hylee17]

@jrrk

thank you for answer. I know I need to set two jumpers. JP1 and JP2

I set JP1[USB/SD] and JP2[SD]

Is there anything else I need to do?

I downloaded fpga.bit and boot.bin from [http://www.lowrisc.org/docs/debug-v0.3/fpga/] -> Run a standalone FPGA demo (no debugger support)

powe on and the green 'done' light... but don't next step...[load boot.bin]

plz help me

[jrrk]

If the green done light comes on it configured OK, you should see a message on the serial port immediately.

If not, try looking for different /dev/ttyUSB* devices

There could be more than one as it is a composite device.

You need to be a member of the dialout group.

Sent from my iPhone

On 28 Oct 2017, at 09:17, hylee17 notifications@github.com wrote:

@jrrk

thank you for answer. I know I need to set two jumpers. JP1 and JP2

I set JP1[USB/SD] and JP2[SD]

Is there anything else I need to do?

I downloaded fpga.bit and boot.bin from [http://www.lowrisc.org/docs/debug-v0.3/fpga/] -> Run a standalone FPGA demo (no debugger support)

plz help me

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hylee17]

@jrrk If "load boot.bin" comes out, it's holding the correct ttyusb port....

There is only ttyUSB0 and ttyUSB1....

[wsong83]

I think you are right on the uart. If you can see "load boot.bin", the bitstream is downloaded and you get the right ttyUSB.

When the "load boot.bin" is showing, a first bootlaoder in the on-chip BRAM is trying to read the boot.bin file from SD and load it to DDR. Without any error message, there is not much to tell what is wrong.

My suggestion, if you would like to, you can run the whole process to rebuild your own fpga bit stream and run the bare-metal tests (see the Makefile in nexys4_ddr for targets like hello, sdcard, memory, etc) There bare-metal tests may help you (or us) find out what is wrong.

[hylee17]

I tried, but it seems that make does not work properly. So I tried prebuilt....

I don't know what the problem is.

[wsong83]

I did have revised debug-v0.3 for a couple of bugfixes, but I do not think these bugfixes would change any functions exposed to the demo. Although I suppose @jrrk can have a try with the prebuilt images to see whether they still work? If not, may be we should just regenerate the prebuilts?

Assuming the prebuilt images are still working, some reasons are still possible to cause the errors you had seen. The micro-SD is not FAT32, the boot.bin is not put at the root directory, or even the micro-SD is not compatible. There are rare cases where certain micro-SD cannot be read by our demo due to some slightly hiccup in the timing of the handshake messages (this is unfortunately of our control as we have tested of our SD cards).

The sdcard bare-metal test can actually confirm most of the above potential causes.

If you say the make does not work properly, at least it should produce error messages? Simply saying something does not work is not very helpful, should I say. We probably could help if we have more information to play with.

[hylee17]

@jrrk @wsong83 Thanks.. I have to test the above sequence. And as a result of checking ... My board is nexys4. Not nexys4_ddr Is there any difference in this?

[jrrk]

I’m sorry your board lacks a DDR memory and cannot run Linux (which requires copious amounts of memory). Perhaps you can sell your board on Ebay and put the proceeds towards the correct board (?)

Sent from my iPhone

On 30 Oct 2017, at 04:47, hylee17 notifications@github.com wrote:

Thanks.. I have to test the above sequence. And as a result of checking ... My board is nexys4. Not nexys4_ddr Is there any difference in this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jrrk]

Having reviewed the Nexys4 datasheet, I can't absolutely rule out running Linux on 16MByte of cellular RAM, but it will most certainly not work with the same images that you are trying to use from a different board. With the help of an experienced designer, you would have rip out the DDR controller from the the top-level verilog and replace it with a static RAM controller, with appropriate changes to the pinout. Also you would might want to convert the kernel to execute-in-place (XIP) operation, working from serial flash, to maximise the available RAM. You would also have to change the memory size on Linux, and the boot procedure memory layout. You would definitely want to enable swapping on the SD-card. I fear your progress towards the goal will be slow, as will the performance of the resulting system. We can't really offer any help with this task, since it is effectively going backwards, compared to our objectives of offering more functionality.

All of this is possible using Vivado and the design we provide, but I'm afraid it will be a steep learning curve unless you have tackled similar projects before.

Begin forwarded message:

From: Dr Jonathan Kimmitt <jrrk2@cam.ac.uk mailto:jrrk2@cam.ac.uk> Date: 30 October 2017 at 07:19:06 GMT To: lowRISC/lowrisc-chip <reply@reply.github.com mailto:reply@reply.github.com> Cc: lowRISC/lowrisc-chip <lowrisc-chip@noreply.github.com mailto:lowrisc-chip@noreply.github.com>, Mention <mention@noreply.github.com mailto:mention@noreply.github.com> Subject: Re: [lowRISC/lowrisc-chip] How long does it take to boot Linux? (#76)

I’m sorry your board lacks a DDR memory and cannot run Linux (which requires copious amounts of memory). Perhaps you can sell your board on Ebay and put the proceeds towards the correct board (?)

Sent from my iPhone

On 30 Oct 2017, at 04:47, hylee17 <notifications@github.com mailto:notifications@github.com> wrote:

Thanks.. I have to test the above sequence. And as a result of checking ... My board is nexys4. Not nexys4_ddr Is there any difference in this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-340342982, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1-ZXLlLdxBmMT-B7eySOL8YR-dwgks5sxVT3gaJpZM4QJ2QV.

[hylee17]

@jrrk @wsong83

I bought the nexys4ddr board and booted Linux successfully.[pre-built] So I tried to build it myself this time but I can not boot.

lowRISC boot program

Load boot.bin into memory Load 4488584 bytes to memory address 87000000 from boot.bin of 4488584 bytes. load elf to DDR memory Boot the loaded program... ../machine/mtrap.c:17: machine mode: unhandlable trap 2 @ 0x0000000080000d24

Outputs the above message and goes into a loop state.

0.3version manual, I created a bitstream and connected it to dev_map.h. [fpga/bootloader/machine/encoding.h and fpga/driver/uart.h]

include "dev_map.h" -> #include "/risc-v/DIR/lowrisc-chip/fpga/board/nexys4_ddr/generated-src/dev_map.h"

What's wrong with the situation right now?

[jrrk]

There is not enough information here. You need to carefully note all steps followed,

and justify any deviation from the instructions.

On 07/11/17 10:20, hylee17 wrote:

@jrrk https://github.com/jrrk @wsong83 https://github.com/wsong83 I bought the nexys4ddr board and booted Linux successfully.[pre-built] So I tried to build it myself this time but I can not boot.

When you say 'build it', do you mean 'build bitstream', 'build linux', 'build bare metal tests' or what ?

lowRISC boot program

Load boot.bin into memory Load 4488584 bytes to memory address 87000000 from boot.bin of 4488584 bytes. load elf to DDR memory Boot the loaded program... ../machine/mtrap.c:17: machine mode: unhandlable trap 2 @ 0x0000000080000d24

Outputs the above message and goes into a loop state.

It looks like the kernel you are running could be wrong. Carefully follow the instructions for building our toolchain and the customised version of Linux again. If you have riscv toolchain for a different version of Rocket in your path, you will get the wrong result. And remember the Linux with its rootfs containing busybox needs to be integrated into BBL in order to work

0.3version manual, I created a bitstream and connected it to dev_map.h. [fpga/bootloader/machine/encoding.h and fpga/driver/uart.h]

include "dev_map.h" -> #include

"/risc-v/DIR/lowrisc-chip/fpga/board/nexys4_ddr/generated-src/dev_map.h"

What's wrong with the situation right now?

I do not understand what you are saying here. It should not be necessary to make manual symbolic links for this flow. That suggests you have failed to set up the environment correctly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-342438149, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF17ohecRITVBKv9Z7cMz-eEdJlprdks5s0C7ogaJpZM4QJ2QV.

[hylee17]

@jrrk Yes. I build bitstream and linux [noDebug]

After the bitstream is successfully created, the following error message is displayed when creating the image file.

---

root@ubuntu:/risc-v/DIR/lowrisc-chip/fpga/board/nexys4_ddr# $TOP/riscv-tools/make_root.sh 2667 blocks build linux... build bbl... configure: WARNING: using cross tools not prefixed with host triplet In file included from ../machine/mtrap.h:4:0, from ../bbl/bbl.c:2: ../machine/encoding.h:6:21: fatal error: dev_map.h: No such file or directory

include "dev_map.h"

                 ^

compilation terminated. make: *** [bbl.o] Error 1

So I created an image file by directly connecting dev_map.h generated from the bitstream.

[jrrk]

Did you follow these instructions (from http://www.lowrisc.org/docs/debug-v0.3/fpga/) to prepare your kernel ?

This is why I emphasize making a note of all step followed, not just the last one.

  Build Linux

|cd $TOP/riscv-tools curl https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.2.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.2.tar.xz | tar -xJ curl -L http://busybox.net/downloads/busybox-1.21.1.tar.bz2 http://busybox.net/downloads/busybox-1.21.1.tar.bz2 | tar -xj cd linux-4.6.2 git init git remote add origin https://github.com/lowrisc/riscv-linux.git https://github.com/lowrisc/riscv-linux.git git fetch git checkout -f -t origin/debug-v0.3 # lowRISC-specific hack for enabling power pin for SD card patch -p1 < spi_sd_power_hack.patch cd $TOP/fpga/board/nexys4_ddr $TOP/riscv-tools/make_root.sh |

On 07/11/17 11:02, hylee17 wrote:

@jrrk https://github.com/jrrk Yes. I build bitstream and linux [noDebug]

After the bitstream is successfully created, the following error message is displayed when creating the image file.

---

root@ubuntu:/risc-v/DIR/lowrisc-chip/fpga/board/nexys4_ddr#
$TOP/riscv-tools/make_root.sh
2667 blocks
build linux...
build bbl...
configure: WARNING: using cross tools not prefixed with host triplet
In file included from ../machine/mtrap.h:4:0,
from ../bbl/bbl.c:2:
../machine/encoding.h:6:21: fatal error: dev_map.h: No such file
or directory
#include "dev_map.h"
^
compilation terminated.
make: *** [bbl.o] Error 1

So I created an image file by directly connecting dev_map.h generated from the bitstream.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-342448557, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF17RTJzyAi0CvIviRoO6-2Z6fs168ks5s0Di0gaJpZM4QJ2QV.

[jrrk]

I can't reproduce your error, it suggests something went wrong when you ran 'source set_env.sh' at the top of your tree,

and $FPGA_BOARD was not set correctly. This is the variable which determines the location of dev_map.h

If so, you will have to put this right and repeat all the other steps to be sure.

On 07/11/17 11:02, hylee17 wrote:

@jrrk https://github.com/jrrk Yes. I build bitstream and linux [noDebug]

After the bitstream is successfully created, the following error message is displayed when creating the image file.

---

root@ubuntu:/risc-v/DIR/lowrisc-chip/fpga/board/nexys4_ddr#
$TOP/riscv-tools/make_root.sh
2667 blocks
build linux...
build bbl...
configure: WARNING: using cross tools not prefixed with host triplet
In file included from ../machine/mtrap.h:4:0,
from ../bbl/bbl.c:2:
../machine/encoding.h:6:21: fatal error: dev_map.h: No such file
or directory
#include "dev_map.h"
^
compilation terminated.
make: *** [bbl.o] Error 1

So I created an image file by directly connecting dev_map.h generated from the bitstream.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-342448557, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF17RTJzyAi0CvIviRoO6-2Z6fs168ks5s0Di0gaJpZM4QJ2QV.

[hylee17]

@jrrk Thank you so much for your advice. So I have more willingness to challenge

I did all the steps as you said.

but, As a result, linux image was created without dev_map.h error because FPGA_BOARD is properly set.

Even though I have repeated all the cases, the following error message is output identically. What can I try?

lowRISC boot program

Load boot.bin into memory Load 4488584 bytes to memory address 87000000 from boot.bin of 4488584 bytes. load elf to DDR memory Boot the loaded program... ../machine/mtrap.c:17: machine mode: unhandlable trap 2 @ 0x0000000080000d24

[jrrk]

There are many things to try to debug the problem.

Have you tried configuring with the known good bitstream and your new Linux?

Have you tried with your new bitstream and the known good linux?

Have you tried the dram test bare metal program with your new bitstream ?

Have you tried disassembling vmlinux (in directory riscv-tools/linux-4.6.2) to find what is at location 80000d24 ?

riscv64-unknown-elf-objdump -d vmlinux >vmlinux.dis

ffffffff80000cf0 : ffffffff80000cf0:       fa010113                addi    sp,sp,-96 ffffffff80000cf4:       00012517                auipc   a0,0x12 ffffffff80000cf8:       31c50513                addi    a0,a0,796 # ffffffff80013010 ffffffff80000cfc:       04813823                sd      s0,80(sp) ffffffff80000d00:       04913423                sd      s1,72(sp) ffffffff80000d04:       04113c23                sd      ra,88(sp) ffffffff80000d08:       05213023                sd      s2,64(sp) ffffffff80000d0c:       03313c23                sd      s3,56(sp) ffffffff80000d10:       03413823                sd      s4,48(sp) ffffffff80000d14:       03513423                sd      s5,40(sp) ffffffff80000d18:       03613023                sd      s6,32(sp) ffffffff80000d1c:       01713c23                sd      s7,24(sp) ffffffff80000d20:       01813823                sd      s8,16(sp) ffffffff80000d24:       01913423                sd      s9,8(sp) ffffffff80000d28:       002e9317                auipc   t1,0x2e9 ffffffff80000d2c:       6e8300e7                jalr    t1,1768 # ffffffff802ea410

Your disassembly should look similar to this, if not you must have the wrong version of one of your sources.

Also, have you tried running 'git submodule', you should get output similar to this:

jrrk2@sigurd:/local/scratch/jrrk2/lowrisc-chip-debug-v0.3$ git submodule  c736c900aed0dc71f5d1189044ef902f6a3627f6 chisel (v2.1-1825-gc736c90)  2c601e0dae4df2691ce70169372055be61791a1d context-dependent-environments (heads/master)  30a93f9b94a3a1e2c3cda9fac88a10db2ace2611 fpga (remotes/origin/update)  b7644fadecd6b11b8dc7b041662feb7bca0c656b hardfloat (b7644fa)  dba420490e6760c7cbb38bd38b61d23dd0d8d4d0 junctions (heads/master)  49f015b09f2ac8f8792cbaea2b112a0f16ba4664 opensocdebug/glip (remotes/origin/proposal-tcpasdefault-9-g49f015b)  6e07c19edddf51ee49d28f74e9039591e674c1fb opensocdebug/hardware (heads/master)  f13da39d94b7848b22df324198f05df69496f1fa opensocdebug/software (heads/master)  1e1b07dfd637d08b2532c0672998a7d46a12a381 riscv-tools (homebrew-166-g1e1b07d)  4fc627569bcfd73b650f4c1daac40d6d4d518936 rocket (heads/master)  718d9c98f50d64d7946be0c9b4ea964ef65519cb socip (heads/master)  7c5292b5067a8b8866cb9710584d77a064f6ca1a uncore (remotes/origin/update) jrrk2@sigurd:/local/scratch/jrrk2/lowrisc-chip-debug-v0.3$

Also have you kept a log of your builds, and examined them for errors due to missing prerequisites etc

Are you using the recommended OS (Ubuntu 14.04.5 LTS - Ubuntu 16.04.3 LTS)

On 07/11/17 13:07, hylee17 wrote:

@jrrk https://github.com/jrrk Thank you so much for your advice. So I have more willingness to challenge

I did all the steps as you said.

but, As a result, linux image was created without dev_map.h error because FPGA_BOARD is properly set.

Even though I have repeated all the cases, the following error message is output identically. What can I try?

lowRISC boot program

Load boot.bin into memory Load 4488584 bytes to memory address 87000000 from boot.bin of 4488584 bytes. load elf to DDR memory Boot the loaded program... ../machine/mtrap.c:17: machine mode: unhandlable trap 2 @ 0x0000000080000d24

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-342476558, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF138DHh0qi3dPoZKddBJBojdlrxn6ks5s0FX3gaJpZM4QJ2QV.

[hylee17]

@jrrk

I have not tried the bare-metal test yet.

The result of executing the objdump command is shown below. It's like a log you uploaded.

ffffffff80000cf0 : ffffffff80000cf0: fa010113 addi sp,sp,-96 ffffffff80000cf4: 00012517 auipc a0,0x12 ffffffff80000cf8: 31c50513 addi a0,a0,796 # ffffffff80013010 ffffffff80000cfc: 04813823 sd s0,80(sp) ffffffff80000d00: 04913423 sd s1,72(sp) ffffffff80000d04: 04113c23 sd ra,88(sp) ffffffff80000d08: 05213023 sd s2,64(sp) ffffffff80000d0c: 03313c23 sd s3,56(sp) ffffffff80000d10: 03413823 sd s4,48(sp) ffffffff80000d14: 03513423 sd s5,40(sp) ffffffff80000d18: 03613023 sd s6,32(sp) ffffffff80000d1c: 01713c23 sd s7,24(sp) ffffffff80000d20: 01813823 sd s8,16(sp) ffffffff80000d24: 01913423 sd s9,8(sp) ffffffff80000d28: 002e9317 auipc t1,0x2e9 ffffffff80000d2c: 6e8300e7 jalr t1,1768 # ffffffff802ea410 ffffffff80000d30: 040007b7 lui a5,0x4000 ffffffff80000d34: fff7879b addiw a5,a5,-1 ffffffff80000d38: 00374697 auipc a3,0x374 ffffffff80000d3c: e9c68693 addi a3,a3,-356 # ffffffff80374bd4

---

I downloaded the source code through the following command. git clone -b debug-v0.3 --recursive https://github.com/lowrisc/lowrisc-chip.git [https://github.com/lowRISC/lowrisc-chip]

The result of executing git submodule command is as follows. Some of the submodules are different. Why is this happening?

4d1d1dc0fe8f21285eb33660692f709dcf251879 chisel (v2.1-1828-g4d1d1dc) 2c601e0dae4df2691ce70169372055be61791a1d context-dependent-environments (heads/master) 0502e01b11bd7041cb782b09c7ec35a2764cf72a fpga (remotes/origin/debug-v0.3) b7644fadecd6b11b8dc7b041662feb7bca0c656b hardfloat (b7644fa) dba420490e6760c7cbb38bd38b61d23dd0d8d4d0 junctions (heads/master) 38648c66fc6866027128bab6c4353bcea8ed0092 opensocdebug/glip (remotes/origin/tcp-dpi-37-g38648c6) 79dd74f2362642e4ae37567cd9bdb322407ddb97 opensocdebug/hardware (79dd74f) ef9f26206cb97c1f309f4997996c87ea2f9300c4 opensocdebug/software (ef9f262) 1e1b07dfd637d08b2532c0672998a7d46a12a381 riscv-tools (homebrew-166-g1e1b07d) b1bb1046d7b18ffe980fa5c4ad0dbde481de0316 rocket (remotes/origin/debug-v0.3) 718d9c98f50d64d7946be0c9b4ea964ef65519cb socip (718d9c9) 569b3f639c9a6452ae55f499102b6d7729e949b6 uncore (remotes/origin/debug-v0.3)

---

The OS of the host environment is UBUNTU 16.04LT.

[jrrk]

Certain bugfixes were backported to the branch you are working on, but the executables were not changed.

It's possible there could be a discrepancy in behaviour between the latest source and the executables you were using.

If you think that might be a problem, you can reproduce approximately the original environment as follows:

git clone https://github.com/lowRISC/lowrisc-chip.git lowrisc-chip-master cd lowrisc-chip-master git checkout 5e49d0a038cf020f4d00077b254ae0fe339f440a git submodule update --init git submodule

 c736c900aed0dc71f5d1189044ef902f6a3627f6 chisel (v2.1-1825-gc736c90)  2c601e0dae4df2691ce70169372055be61791a1d context-dependent-environments (heads/master)  30a93f9b94a3a1e2c3cda9fac88a10db2ace2611 fpga (remotes/origin/untether-v0.2-38-g30a93f9)  b7644fadecd6b11b8dc7b041662feb7bca0c656b hardfloat (b7644fa)  dba420490e6760c7cbb38bd38b61d23dd0d8d4d0 junctions (heads/master)  49f015b09f2ac8f8792cbaea2b112a0f16ba4664 opensocdebug/glip (remotes/origin/tcp-dpi-15-g49f015b)  6e07c19edddf51ee49d28f74e9039591e674c1fb opensocdebug/hardware (6e07c19)  f13da39d94b7848b22df324198f05df69496f1fa opensocdebug/software (f13da39)  1e1b07dfd637d08b2532c0672998a7d46a12a381 riscv-tools (homebrew-166-g1e1b07d)  4fc627569bcfd73b650f4c1daac40d6d4d518936 rocket (4fc6275)  718d9c98f50d64d7946be0c9b4ea964ef65519cb socip (718d9c9)  7c5292b5067a8b8866cb9710584d77a064f6ca1a uncore (7c5292b)

Then proceed with the same instructions as before.

Be sure to make sure you are using Vivado-2015.4 - there are known issues with newer versions.

[hylee17]

@jrrk

root@ubuntu:/risc-v/DIR/lowrisc-chip-master# git submodule c736c900aed0dc71f5d1189044ef902f6a3627f6 chisel (v2.1-1825-gc736c90) 2c601e0dae4df2691ce70169372055be61791a1d context-dependent-environments (heads/master) 30a93f9b94a3a1e2c3cda9fac88a10db2ace2611 fpga (remotes/origin/untether-v0.2-38-g30a93f9) b7644fadecd6b11b8dc7b041662feb7bca0c656b hardfloat (b7644fa) dba420490e6760c7cbb38bd38b61d23dd0d8d4d0 junctions (heads/master) 49f015b09f2ac8f8792cbaea2b112a0f16ba4664 opensocdebug/glip (remotes/origin/tcp-dpi-15-g49f015b) 6e07c19edddf51ee49d28f74e9039591e674c1fb opensocdebug/hardware (6e07c19) f13da39d94b7848b22df324198f05df69496f1fa opensocdebug/software (f13da39) 1e1b07dfd637d08b2532c0672998a7d46a12a381 riscv-tools (homebrew-166-g1e1b07d) 4fc627569bcfd73b650f4c1daac40d6d4d518936 rocket (4fc6275) 718d9c98f50d64d7946be0c9b4ea964ef65519cb socip (718d9c9) 7c5292b5067a8b8866cb9710584d77a064f6ca1a uncore (7c5292b)

But, the nexys4_ddr directory is empty.....

Is it different from the version below?

################

Version 0.2: untethered lowRISC (12-2015)

################ git clone -b untether-v0.2 --recursive https://github.com/lowrisc/lowrisc-chip.git

I am using vivado 2015.04... Should I try version 0.4?

[hylee17]

@jrrk I did a 0.3 version bare-metal test. Is there a memory problem?

UART : OK SDCARD : OK DRAM : ERROR

[jrrk]

You have badaddr==88000000 which is the end of the (128M) RAM. So I would say it is OK, but I did not write this program.

You can experiment with changing the end address in the source. I do not think it should go beyond 128M.

You have not confirmed what version of Vivado you are using.

On 08/11/17 06:21, hylee17 wrote:

@jrrk https://github.com/jrrk I did a 0.3 version bare-metal test. Is there a memory problem?

UART : OK
SDCARD : OK
DRAM : ERROR

image https://user-images.githubusercontent.com/32116397/32534332-76fe7290-c498-11e7-9a49-a10912102e09.png

image https://user-images.githubusercontent.com/32116397/32534349-85fd596e-c498-11e7-8674-2c1909efa858.png

image https://user-images.githubusercontent.com/32116397/32534354-89ebb584-c498-11e7-8583-b28abd5e5f02.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-342722308, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1xdLMf8NCWesG73xIn32sHq0ymGuks5s0UiAgaJpZM4QJ2QV.

[hylee17]

Is it okay because you say that error message is the last address in memory?

My Vivado is 2015.04 version.

[hylee17]

@jrrk In order to check whether it is a bitstream problem or a Linux image problem, I have made the following points.

1. make bitstream + pre-built linux [boot success]
2. pre-built bitstream + make linux [boot failure] Therefore, there seems to be a problem creating a Linux image file.

[jrrk]

I know this seems like a lame response, but have you tried the |untether-v0.2 release or the minion-v0.4 release? This might give more information as to whether there is a problem of compatibility of your board. If there is a problem with building Linux it might be related to the toolchain being incompatible with your build environment (or a dependency I do not know about). One definite thing to be aware of is that you cannot use the same toolchain with different releases.

I think I have ground to a halt with suggestions as to what could be wrong but it is a lesson for me on the kind of issues users might encounter. Perhaps we will move to a docker based system for the next release because it seems there is quite a bit of variability in results here. |

On 08/11/17 13:15, hylee17 wrote:

@jrrk https://github.com/jrrk In order to check whether it is a bitstream problem or a Linux image problem, I have made the following points.

1. make bitstream + pre-built linux [boot success]
2. pre-built bitstream + make linux [boot failure] Therefore, there seems to be a problem creating a Linux image file.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-342814141, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF17HY8SIcJqGIo3PwSV9kWJ_M-uacks5s0alrgaJpZM4QJ2QV.

[asb]

Docker has its own problems. Pre-built static binaries (or dynamically linked binaries built on an old RHEL) is probably a good option. It sounds like you're building and using the riscv-tools associated with the correct release though (perhaps double check there's not another version of the tools in your PATH that is being used instead). Tracking down the issue to the linux image built on your machine is good progress, but I'm not full of ideas about what might be wrong beyond the obvious toolchain versioning questions.

[hylee17]

@jrrk @asb First, I reinstalled the 0.3 version of the toolchain. There were no errors in the installation process.

---

root@ubuntu:/risc-v/DIR11/lowrisc-chip/fpga/board/nexys4_ddr# riscv64-unknown-elf-gcc --version riscv64-unknown-elf-gcc (GCC) 6.1.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@ubuntu:/risc-v/DIR11/lowrisc-chip/fpga/board/nexys4_ddr# riscv64-unknown-linux-gnu-gcc --version riscv64-unknown-linux-gnu-gcc (GCC) 6.1.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But still prints the same error message when booting the image.

lowRISC boot program

Load boot.bin into memory Load 4488584 bytes to memory address 87000000 from boot.bin of 4488584 bytes. load elf to DDR memory Boot the loaded program... ../machine/mtrap.c:17: machine mode: unhandlable trap 2 @ 0x0000000080000d24

Also, I tried 0.4version. As with 0.3version, bitstream and Linux images were generated without error. Even though I did it in no-debug mode[standalone FPGA demo], the following selftest is output, and no input is received.

selftest>

---

Would I be tempted to try the 0.2version?

[jrrk]

For the 0.4 release, what happens if you reset with SW1 high (the rightmost but one on the bottom right of the Digilent board). Or if you have a PC keyboard and VGA monitor available, you could connect them and see if there is any response to input. Or you could try a bare metal boot program:

make boot cfgmem-updated program-cfgmem-updated

Did you read the bit about only cfgmem configuration being supported?

Sent from my iPhone

On 9 Nov 2017, at 02:06, hylee17 notifications@github.com wrote:

@jrrk @asb First, I reinstalled the 0.3 version of the toolchain. There were no errors in the installation process.

root@ubuntu:/risc-v/DIR11/lowrisc-chip/fpga/board/nexys4_ddr# riscv64-unknown-elf-gcc --version riscv64-unknown-elf-gcc (GCC) 6.1.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@ubuntu:/risc-v/DIR11/lowrisc-chip/fpga/board/nexys4_ddr# riscv64-unknown-linux-gnu-gcc --version riscv64-unknown-linux-gnu-gcc (GCC) 6.1.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But still prints the same error message when booting the image.

lowRISC boot program

Load boot.bin into memory Load 4488584 bytes to memory address 87000000 from boot.bin of 4488584 bytes. load elf to DDR memory Boot the loaded program... ../machine/mtrap.c:17: machine mode: unhandlable trap 2 @ 0x0000000080000d24

Also, I tried 0.4version. As with 0.3version, bitstream and Linux images were generated without error. Even though I did it in no-debug mode[standalone FPGA demo], the following selftest is output, and no input is received.

selftest>

Would I be tempted to try the 0.2version?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hylee17]

@jrrk make boot cfgmem-updated program-cfgmem-updated When I use the above command to program, Repeat infinitely as shown in the following figure. [0.4version]

This time I tried 0.2version. It was created without error in generating image and bitstream. As a result of the test, the following error message is output. However, when testing sdcard, I read the test.txt file correctly.

If I try with different versions, I installed a new toolchain for each version and set the PATH correctly. I'm sure. This behavior seems to have repeated over 30 times.....haha...

The tool-chain installation of 0.2 version is installed through the following site, and installation is completed without error. [http://www.lowrisc.org/docs/untether-v0.2/riscv_compile/]

After completing the installation, I created busybox and kernel image. [http://www.lowrisc.org/docs/untether-v0.2/linux_compile/]

I used the spike tool to verify the image. [booting success] cd $TOP/riscv-tools/ spike +disk=busybox-1.21.1/root.bin bbl linux-3.14.41/vmlinux

Next, I created a bitstream and created a boot loader (BBL). [http://www.lowrisc.org/docs/untether-v0.2/fpga-demo/]

make boot

make bbl

So, I tried to boot up the program by putting a total of 4 files (root.bin, vmlinux, chip_top.new.bit, bbl) into SDCARD.

But the result is Fail to mount SD driver! error! Same as exit (0x0000000000000001).

I modified set_riscv_env.sh and executed it. The modifications are FPGA_BOARD = kc705 -> FPGA_BOARD = nexys4.

Now all the process goes smoothly without any errors, but I do not know why for some reason it will not boot.

[jrrk]

I'm sorry you haven't had much success, despite working very hard on the problem.

Perhaps you should try a different make of SD-card in case that is causing the issue.

For the 0.4 version, did you remember to set the configuration source to QSPI ?

If you use SD-card configuration it sets the card to SPI-mode which is incompatible with the v0.4 release.

For the ethernet-v0.5 release (not documented yet), it is possible to boot up from Ethernet which might solve the problem of the vagaries of different cards. Let me know if you want to be a beta tester of this.

It is intended for motivated people who want to investigate and learn, rather than users who want a shrink-wrapped product.

Obviously all your feedback is useful to incorporate into improved releases in the future.

On 10/11/17 13:19, hylee17 wrote:

@jrrk https://github.com/jrrk make boot cfgmem-updated program-cfgmem-updated When I use the above command to program, Repeat infinitely as shown in the following figure. [0.4version] image https://user-images.githubusercontent.com/32116397/32659637-fe236e58-c662-11e7-9e73-f1b9e7084c16.png

This time I tried 0.2version. It was created without error in generating image and bitstream. As a result of the test, the following error message is output. However, when testing sdcard, I read the test.txt file correctly. image https://user-images.githubusercontent.com/32116397/32659707-514ad68e-c663-11e7-9c9e-138cbc612fa6.png

If I try with different versions, I installed a new toolchain for each version and set the PATH correctly. I'm sure. This behavior seems to have repeated over 30 times.....haha...

The tool-chain installation of 0.2 version is installed through the following site, and installation is completed without error. [http://www.lowrisc.org/docs/untether-v0.2/riscv_compile/]

After completing the installation, I created busybox and kernel image. [http://www.lowrisc.org/docs/untether-v0.2/linux_compile/]

I used the spike tool to verify the image. [booting success] cd $TOP/riscv-tools/ spike +disk=busybox-1.21.1/root.bin bbl linux-3.14.41/vmlinux

Next, I created a bitstream and created a boot loader (BBL). [http://www.lowrisc.org/docs/untether-v0.2/fpga-demo/]

make boot

make bbl

So, I tried to boot up the program by putting a total of 4 files (root.bin, vmlinux, chip_top.new.bit, bbl) into SDCARD.

But the result is Fail to mount SD driver! error! Same as exit (0x0000000000000001).

I modified set_riscv_env.sh and executed it. The modifications are FPGA_BOARD = kc705 -> FPGA_BOARD = nexys4.

Now all the process goes smoothly without any errors, but I do not know why for some reason it will not boot.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-343471216, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1zoysTnPale3QPZVN4nN5e6Hr0YTks5s1E1jgaJpZM4QJ2QV.

[hylee17]

@jrrk What does "try a different make of SD-card" mean? If it's a sd card issue, should not pre-built images and bitstreams fail to boot?

I don't want rely on chip peripherals. Porting linux to a rocket-chip with a very basic configuration.

Nevertheless, I would like to test 0.5version also. I want to make a successful one and then fix it.

Where is the 0.5version guide and the source code?

[jrrk]

On 10/11/17 14:22, hylee17 wrote:

@jrrk https://github.com/jrrk What does "try a different make of SD-card" mean?

I only meant different vendors of SD-card might have different requirements on timing and so on. This is particularly relevant for the v0.4 release where the SD-card is used in SD-mode (instead of SPI-mode)

If it's a sd card issue, should not pre-built images and bitstreams fail to boot?

SD-cards are very sophisticated devices, with their own built-in redundancy and timing variations. The act of copying a new image onto the card could, in theory, change the timing of the boot operation. You can try reformatting your SD-card under Linux using the fdisk and mkfs.msdos commands to see if it helps. If you have a big card, chose a small partition size of 16Megs or so to ensure the kernel will be located near the beginning of the card. Also the boot loader has a simplified version of MSDOS filing system and it might not like it if the sector layout is different from what it is expecting. In theory you can try this program under Linux and see if it is reading the card properly, but this is a bit beyond the scope of what you are attempting at this stage.

I do not rely on devices around the chip. Porting linux to a rocket-chip with a very basic configuration.

Nevertheless, I would like to test 0.5version also. I want to make a successful one and then fix it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-343485743, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF16IUuKGlXf9BXzUtlCHoMASjaGYlks5s1FwUgaJpZM4QJ2QV.

[jrrk]

If you want to try ethernet-v0.5 pre-release, proceed as follows (adjusting as necessary to suit your environment):

git clone -b ethernet-v0.5 https://github.com/lowRISC/lowrisc-chip.git --recursive lowrisc-chip-ethernet-v0.5 cd lowrisc-chip-ethernet-v0.5 source set_env.sh cd riscv-tools/ bash build.sh cd riscv-gnu-toolchain cd build/ ../configure --prefix=$RISCV make linux -j 4 cd ../.. cd ../fpga/board/nexys4_ddr/ source /opt/Xilinx/Vivado/2015.4/settings64.sh # Your Xilinx tools could be installed elsewhere unset LD_LIBRARY_PATH make bitstream make cfgmem make program-cfgmem pushd ../../../riscv-tools/ sh fetch_and_patch_busybox.sh sh fetch_and_patch_linux.sh pushd make boot0000.bin

Your card may get mounted elsewhere

sudo mount /dev/sde1 /mnt sudo cp boot0000.bin /mnt/ sudo rm /mnt/* sudo umount /mnt

Replace card and turn-on SW1, ensure MODE switch is QSPI, reconfigure board

On 10/11/17 14:22, hylee17 wrote:

@jrrk https://github.com/jrrk What does "try a different make of SD-card" mean? If it's a sd card issue, should not pre-built images and bitstreams fail to boot?

I do not rely on devices around the chip. Porting linux to a rocket-chip with a very basic configuration.

Nevertheless, I would like to test 0.5version also. I want to make a successful one and then fix it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-343485743, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF16IUuKGlXf9BXzUtlCHoMASjaGYlks5s1FwUgaJpZM4QJ2QV.

[hylee17]

@jrrk The same is true for booting with pre-built.[0.4version] If I enter "B" command, it will not boot up with the following message.

Is it really a sdcard problem? Do I have to buy another company's sdcard?

---

I have a few questions to read about your answers.

What is the meaning of "unset LD_LIBRARY_PATH" in progress of 0.5 version? I did not use the above command when I made it at 0.2, 0.3, 0.4.

And is "sh fetch_and_patch_busybox.sh" simply a command to create busybox?

Finally, when I program the image and bitstream on the sdcard, I dragged it directly in the Windows environment, not in the Linux environment.

Is there a difference between using "mount" and "cp" commands in a Linux environment?

[jrrk]

Now you’ve gone to this trouble, why not attach a close-up picture of your board to see if everything is as I expect. For v0.4 the QSPI position needs to be used.

Sent from my iPhone

On 10 Nov 2017, at 17:08, hylee17 notifications@github.com wrote:

@jrrk The same is true for booting with pre-built.[0.4version] If I enter "B" command, it will not boot up with the following message.

Is it really a sdcard problem? Do I have to buy another company's sdcard?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hylee17]

@jrrk

oh .. I'm sorry. I could not hear your advice, I was doing it with JP1 [SD]. I'm really sorry..

After changing to JP1 [QSPI], Linux booted up at boot time. [0.4 ver / pre-built]

So, I will now build and test the 0.4 version myself. [Image / bitstream] Of course, 0.5 version is going to be done.

Is it possible to boot from 0.3version and 0.2version with the same problem? Is setting JP1 [QSPI] an essential option?

And is it impossible to test with UART without VGA and KEYBOARD in 0.4 version?

[hylee17]

@jrrk I have created and tested image files and bitstreams. As a result, it will not boot Linux with the following message. [stop]

The message is different from 0.3version. But in the end it seems that there is a problem creating a Linux image.

As a result of comparing with pre-built, pre-built also prints the same message but succeeds to boot Linux.

pre-built root.bin [image] + generation bitstream [chip_top.new.bit] -> boot success generation root.bin [image] + generation bitstream [chip_top.new.bit] -> boot fail

---

The process to generate the image is as follows.

cd $ TOP / riscv-tools curl -L http://busybox.net/downloads/busybox-1.21.1.tar.bz2 | tar -xj sh $ TOP / riscv-tools / fetch_and_patch_linux.sh [I entered "y"]

cd $ TOP / fpga / board / nexys4_ddr $ TOP / riscv-tools / make_root.sh

---

And I compared the size of the pre-built image and the size of the image that I generated directly.

[jrrk]

At v0.4 and later, we moved to the SD-mode of the SD-card, previously we were using

SPI-mode. If you use SD-card as the configuration mode, it forces the SD-card to SPI-mode

and stops it from working. This is not a problem in v0.2 and v0.3

You can use USB-memory stick mode with v0.4 but it prevents a keyboard from being plugged in.

You can also use JTAG mode, but it only lasts for one boot, and then it has to be reprogrammed.

You can use v0.4 onwards without keyboard+monitor but it might require you to type ctrl-J at the end of boot commands instead of return/enter depending on your terminal settings.

On 11/11/17 03:02, hylee17 wrote:

@jrrk https://github.com/jrrk

oh .. I'm sorry. I could not hear your advice, I was doing it with JP1 [SD]. I'm really sorry..

After changing to JP1 [QSPI], Linux booted up at boot time. [0.4 ver / pre-built]

So, I will now build and test the 0.4 version myself. [Image / bitstream] Of course, 0.5 version is going to be done.

Is it possible to boot from 0.3version and 0.2version with the same problem? Is setting JP1 [QSPI] an essential option?

And is it impossible to test with UART without VGA and KEYBOARD in 0.4 version?

image https://user-images.githubusercontent.com/32116397/32685548-f736d426-c6d6-11e7-8a6a-6d326882be4d.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-343635652, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF19kv5BoOQKmyt9fgig34JVS9siyuks5s1Q47gaJpZM4QJ2QV.

[jrrk]

After you mentioned your difficulties, I noticed there could be a problem compiling the toolchain if the

version of host gcc was too old or too new. I manually installed (host) gcc-4.5.0 from source and this solved the problem.

I don't know if you are familiar with this procedure. By default, it installs in /usr/local/bin and will be used in the toolchain build.

If too old, it will complain about unsupported C++ standard, if too new it will bomb out due to less than sanitary coding practices (that do not matter for our purposes). We do not want to spend time on this toolchain because we are working on a replacement that uses LLVM, a much more modern concept.

Regarding the MD5 check, you can add a boot.md5 onto the card, which, if present, indicates the expected result.

On your workstation:

md5sum boot.bin > boot.md5

copy boot.bin and boot.md5 onto the SD-card.

This will ensure there is one less thing to go wrong.

On 11/11/17 05:15, hylee17 wrote:

@jrrk https://github.com/jrrk I have created and tested image files and bitstreams. As a result, it will not boot Linux with the following message. [stop]

The message is different from 0.3version. But in the end it seems that there is a problem creating a Linux image.

As a result of comparing with pre-built, pre-built also prints the same message but succeeds to boot Linux.

pre-built root.bin [image] + generation bitstream [chip_top.new.bit] -> boot success generation root.bin [image] + generation bitstream [chip_top.new.bit] -> boot fail

image https://user-images.githubusercontent.com/32116397/32686589-b956eec0-c6ea-11e7-82d4-506c0e0c562f.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/76#issuecomment-343641772, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1_D1tLD8T8vi5bmQr5l3sBKnsZJNks5s1S1igaJpZM4QJ2QV.

[hylee17]

@jrrk

The gcc installed in my host environment is 5.4.1version ... I will install gcc 4.5.0 and try again.

Thank you for your sincere advice.

gcc-4.5.0 is a very old version. Currently, ubuntu-16.04LT does not support installation, how can I install it?

I found that I used gcc-4.8 when I looked at the guide document. Can I install it with gcc-4.8?

[hylee17]

@jrrk I downgraded the GCC version and created an image file. As a result, Linux boot on the FPGA was successful. Thank you for your advice.

I will modify the rocket core in the future and try to boot linux. Thank you.