[GSoC] Debug Bootblock Stage for ARMv8 on QEMU

Hello again, I’m Asami. I’ve just finished 4 weeks as a GSoC student. I’m currently debugging the implementation of my main project, which is adding QEMU/AArch64 support. I can see nothing output right now when I start a QEMU with the coreboot.rom that has my implementation. It means there is something wrong before a hardware initialization has finished. In this article, I’m going to talk about what I found while debugging the bootblock for ARMv8.

Code Path of Bootblock Stage

The bootblock is executed just after CPU reset and it is almost written by assembly language. The main task is to set up a C-environment. The basic code path for ARMv8 from the beginning the bootblock to the romstage is:

  1. _start() at src/arch/arm64/armv8/bootblock.S
  2. arm64_init_cpu() at src/arch/arm64/armv8/cpu.S
  3. main() at srclib/bootblock.c
  4. run_romstage() at src/lib/prog_loaders.c
  5. prog_run() at src/lib/prog_ops.c
  6. arch_prog_run() at src/arch/arm64/boot.c
  7. main() at src/arch/arm64/romstage.c // The entry point of the romstage

You can use your custom _start function instead of the common _start function by CONFIG_BOOTBLOCK_CUSTOM=y and adding bootblock-y += bootblock_custom.S which is your custom assembly file.

The Reason Why Execution Stopped inside arm64_init_cpu()

I found that an execution stopped inside the arm64_init_cpu function for some reason. The line that has some problem is mrs x22, sctlr_el3 . MRS instruction can read a system control register and store the value into a general purpose register. So this line means to store the value of SCTLR_EL3 into the X22 register.

According to the “ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile”, the purpose of SCTLR_EL3 is

Provides top level control of the system, including its memory system, at EL3. This register is part of the Other system control registers functional group.

Also, SCTLR_EL3 is accessible only from EL3 mode. EL3 is the highest privileged mode that a low-level firmware, including the secure monitor, works on it.

Next, I checked the current mode via mrs x0, CurrentEL. CurrentEL is a register that holds the current exception level. The result of CurrentEL was 0x04, which means the program works on EL1 mode. EL1 is the mode that an operating system kernel typically described as privileged. I didn’t have the right to access SCTLR_EL3. That’s why an execution stopped.

Ideas to Solve EL3 Issue

I considered 2 solutions:

  1. Use only EL1 registers
  2. Run QEMU in EL3

Firstly, I tried to use only EL1 registers. I replaced arm64_init_cpu with arm64_init_cpu_el1 that is a new function I created. Then I replaced SCTLR_EL3 with SCTLR_EL1 and TLBI ALLE3 with TLBI VMALLE1. It seems to work well but still, there was nothing output.

Secondly, I tried to run QEMU in EL3 that is enabled by -machine flag. QEMU can work on EL2 with -machine virtualization=on and EL3 with -machine secure=on to enable EL3. The following command works well for me.

$ qemu-system-aarch64 -bios ./build/coreboot.rom -M virt -cpu cortex-a53 -nographic -smp 1 -machine secure=on

My mentor Raul told me the second solution. Thank you so much!

GSoC2011(Week 9): boot ARM using coreboot to romstage

Hi all. Here I come again. With one week’s work, coreboot now can add romstage to the romfile, pass control to the romstage and find ramstage. I add a new way using a binary file to add stage to a rom file. Since I have not got an idea of how to store the hardware information, no hardware initialization is done now except the console. Following I will show you some snapshots:
This is a romfile without ramstage so it hangs at finding it:

This is a romfile with a simple ramstage. The ramstage code only sends a string “Hello ARM!” to the console then hangs there. It is compressed using LZMA in the romfile and should be decompressed and copied to the RAM at address 0x5000. This romfile is for testing the decompress function and move-jump function.

Next week, I will work on the ramstage. It is one of the hardest parts since we will deal with the hardware information. I need to design it and implement it. I want my code to be tested and reviewed early for that it is not only about implementation but also design. One could change an implementation with a low cost but couldn’t change a design with a low cost.
Thanks to God and Thanks to all the coreboot developers. Working with you all is so happy and fantastic!

GSoC2011: midterm report

Hi all. Welcome to my midterm report for project “porting coreboot to ARM”.

Summary

The goal of this project is porting coreboot to ARM and taking advantage of coreboot’s strength in properly configuring PCI, SAS, SATA and SCSI devices; fast boot times; and payload support.

For ARM SOCs, the device configuring is much easier than that for X86. Most device controllers are connected through the on-chip bus. So the mainly work is focus on porting the basic layout and helping tools to ARM architecture, including CBFS, cbfstool and the codes helping loading next stage and payload into ram.

Changes to this project

At first, I want to work on Marvell ARM SOCs with PCIE support, but after checking into it, I found that mostly all the information and SDK of Marvell SOCs are covered under an NDA license. So I moved to VersatilePB from Armltd.

What works now

  • CBFS record the architecture information in the master header
  • cbfstool can detect the architecture of a rom file
  • cbfstool can create an ARM rom file with bootblock
  • bootblock for VersatilePB is ready for use
  • romstage code for VersatilePB has been written

What doesn’t work (yet)

  • cbfstool can not add-stage to the romfile due to a problem in prase_elf_to_stage
  • romstage for VersatilePB has not been tested
  • ramstage code for VersatilePB has not been written

What needs work

  • design the information struct of hardware for payload on ARM

In this week, I will try to fix the problem of add-stage on ARM and test the romstage code.
Got any feature suggestions/ideas ?

GSoC2011(Week 5): the layout of coreboot rom and cbfstool for ARM

Hi all. How time flies. It has been 4 weeks since my last post. During this month, I have finished the design and implement of bootblock, Rom structure and cbfstool for ARM. Following I will show my changes to you all.
Continue reading GSoC2011(Week 5): the layout of coreboot rom and cbfstool for ARM

GSoC2011(Week 1): Analysis of U-boot ARM boot code

This is such a busy week. At the end of last week, I have just ordered my OpenRD-Ultimate box but sadly it will be delivered at the end of June. So if I just wait for that box, I will not be able to test my code. That’s terrible! After talking with my mentor, I decided first porting coreboot to RealView Versatile/PB926EJ-S board then to OpenRD-Ultimate. Since qemu can emulate PB926EJ-S, I can test my code on it quickly and freely. After this work, the basic layout, libs and headers for ARM are ready to use. So I can start to port coreboot to OpenRD-Ultimate then.
Continue reading GSoC2011(Week 1): Analysis of U-boot ARM boot code

GSoC2011 Project: Porting coreboot to ARM architecture

I am so excited that my idea on porting coreboot to ARM architecture has been accepted by GSoC project this year. First, let me introduce myself to you all. I am now a junior student at Hebei University of Technology, People’s Republic of China. My major is Computer Science and Technology. Although my courses are almost focus on high-level software development like database system and software engineering, I am a fan of low-level development. I taught myself IA32 and ARM architecture last year. And during this summer, we will porting coreboot to ARM and make it a new bootloader for ARM.

Those days, I am studying the building system of coreboot deeply, and I am trying to add cross-compile toolchain support to it. Developers has created such a great system and I want to make it greater. 🙂

Thanks for reading my project and any comment is welcome.