Linux boot procedure

[hylee17]

@jrrk

Hi. I have been here a long time.

I want to know the Linux boot procedure of LowRISC.

Is there any place to get related documents?

[jrrk]

Dear hylee17,

I assume you have studied the materials on our website lowrisc.org already.

With the latest release ethernet-v0.5, there is a choice of boot methods.

The new method is known as etherboot and is a cut down version of the procedure that

happens when you press F12 on your PC keyboard in the BIOS to boot from the network.

Stage 1: The FPGA needs to be configured from QSPI flash (or JTAG, or USB stick) an on-board PIC does this.

Stage 2: The configured FPGA contains a ROM (actually a RAM) preloaded with the bare metal boot program.

The source code of this program is in fpga/bare_metal/examples/boot.c of our repository.

There is a choice of boot methods depending on the switch settings.

Option 1: SD-boot: The Berkeley Boot Loader (BBL) is loaded from secure digital card plugged into the board.

The loaded program is an ELF file containing BBL with the Linux Kernel appended. A choice of kernels is possible

according to switch settings.

Option 2: Etherboot: The bare metal boot loader advertises its presence at 192.168.0.51 on the network to incoming ARP queries.

Each 1024 byte segment of the BBL+kernel is sent over the network as an UDP packet. The bare metal loader maintains a bitmap

of all packet successfully received and reports to the host when asked. When the host is satisfied all packets are received, it requests

an MD5 checksum of the BBL+kernel, and if correct, it sends the boot command. There will be no reply to this command so it sends

it several times to make sure.

Stage 3: After BBL+kernel is received by either method BBL launches in machine mode and sets up the machine mode trap vectors.

It then calls the Linux kernel in supervisor mode, making sure its start address is aligned with a megapage. Locations of devices are discovered

by reading a bootrom which is located at 0x10000 inside the Rocket.

Regards,

Jonathan

On 23/01/18 04:53, hylee17 wrote:

@jrrk https://github.com/jrrk

Hi. I have been here a long time.

I want to know the Linux boot procedure of LowRISC.

Is there any place to get related documents?

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

[hylee17]

@jrrk

Dear Jonathan,

Thank you for always giving me the answers of this sincere kind.

I am currently studying with 0.3version or 0.4version.

I am wondering if there is any documentation to study to understand the Linux boot procedure of 0.3version.

I tried to find a document about a boot loader (bbl) made by Berkeley, but it failed. [Also, some of them were requesting a bbl document from Google.]

The reasons for studying the boot loader[First Stage Bootloader and Second Stage Bootloader] are as follows.

I am wondering if there is an impact on the Linux boot when we modify the Rocket Core.

1. Add command

2. Add Exception

3. Modify the memory area [I suspect this will be affected.]

I heard that LowRISC modified the original BBL.

Are the modifications made to implement tagged memory or by other implementations?

I am sorry that the question is a very basic question.

Regards,

HeeYeol

[jrrk]

Dear HeeYeol,

The boot procedure of the 0.3 version is as I described for the 0.5 version but etherboot is not an option,

and the SD-card reads are replaced by Vivado IP that does SPI card reads (with the 1-bit mode of the same card)

The BBL that we are using is modified to send its messages via UART instead of using the HTIF interface which requires a separate host (typically an ARM Zync board). It does not make use of tagged memory but it would be a good thing in future for secure booting. It lags behind the latest Rocket privilege architecture. However the memory area is reduced because of the area set aside for tags.

In the 0.4 version booting goes via a separate Minion core. This turned out to be a bottleneck in the procedure, so in the 0.5 version we went back to controlling booting directly from the Rocket.

You asked about exceptions. External exceptions are not used pre 0.5 version. They have a very beneficial effect on performance, particularly for Ethernet and SD-card peripherals.

I don't know what you mean by add command. If you mean add new instructions, I would not expect much impact unless a block copy or DMA command was added.

There is no detection of memory size. This is hardwired at the Chisel stage and in the bare metal boot loader mentioned previously.

So it sounds like if you want to study exceptions, it would be best to move to the 0.5 version.

Regards, Jonathan

On 23/01/18 11:46, hylee17 wrote:

@jrrk https://github.com/jrrk

Dear Jonathan,

Thank you for always giving me the answers of this sincere kind.

I am currently studying with 0.3version or 0.4version.

I am wondering if there is any documentation to study to understand the Linux boot procedure of 0.3version.

I tried to find a document about a boot loader (bbl) made by Berkeley, but it failed. [Also, some of them were requesting a bbl document from Google.]

The reasons for studying the boot loader[First Stage Bootloader and Second Stage Bootloader] are as follows.

I am wondering if there is an impact on the Linux boot when we modify the Rocket Core.

1.

Add command

2.

Add Exception

3.

Modify the memory area [I suspect this will be affected.]

I heard that LowRISC modified the original BBL.

Are the modifications made to implement tagged memory or by other implementations?

I am sorry that the question is a very basic question.

regards,

HeeYeol

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