[GSoC] coreboot for ARM64 Qemu – Week #6

This week I worked on completing the build and sorting all complications imposed by it. As I talked in the last post, I was facing some issues regarding setting up smp for this port. I solved this issue by adding an assembly file which declared smp_processor_id and then defined it by setting the right registers. I had to do some background reading on arm64 details. This provided me with the information I needed.

Next up, was another hitch. During the build, ‘mmu_enable()’ and ‘arch_secondary_cpu_init()’ function calls are happening for all stages but the definitions for these functions are getting compiled only for ramstage. So this gave recurrent errors since the compiler couldn’t find these definitions. While attempting to sort this, I stumbled across something on the chromium tree. There was a patch which dealt with some of the issues, similar to mine. I had to cherry pick and apply this change.

After debugging and sorting through some more errors, I was finally able to get it to build successfully.

coreboot.rom: 4096 kB, bootblocksize 37008, romsize 4194304, offset 0x90c0 alignment: 64 bytes, architecture: arm64

Name                                       Offset     Type         Size
fallback/romstage               0x90c0     stage        12108
fallback/ramstage               0xc080     stage        17768
config                                    0x10640    raw          2034
revision                                0x10e80    raw          577
(empty)                                 0x11100    null         4124312
      HOSTCC     cbfstool/rmodtool.o
     HOSTCC     cbfstool/rmodule.o
     HOSTCC     cbfstool/rmodtool (link)
The complete build can be found here.
I attempted to boot off on qemu after this,
$qemu-system-aarch64 -machine type=virt -nographic -bios ~/coreboot/build/coreboot.rom
This did not give any output, which meant probably I had to make some changes in the uart set up. I attempted to debug this by adding few printks early in bootblock once the console_init is done. This process ongoing, I hope to get through. Another aspect in question is the bootblock initialisation. The src/arch/arm64/armv8/bootblock_simple.c calls for an appropriate bootblock_cpu_init(). This is another thing I will be working on in the coming days.

[GSoC] EC/H8S firmware week #6

This week I looked at the communication between the EC H8S and the PMH4. The PMH4 (likely power management hub) is an ASIC which takes care of the power control. It controls who get’s power and who not. It doesn’t do any high level work, more like a big logic gatter. The PMH4 has inputs from several power good pins from different power rails and chips. On the output side it controls some power rails. It can also reset the H8S. The PMH4 also knows over some pins in which power state (ACPI S0,S4,S5) the board is. It doesn’t do any high level work. It’s more like a big logic gatter. There are no ADC on any power lines.

The PMH4 is connected to the H8S via 4 Pins. ~OE LE DATA CLK.

gsoc 2015 pmh4 connector t40

I connected a buspirate in SPI sniffer mode to debug the protocol. But the output looked a little bit strange. There was no data from the PMH4 to H8S (MISO) and the data comes in burst. To get more knowledge on the protocol I used a digital oscilloscope.

pmh4 oscilloscope

The protocol doesn’t look like SPI. LE get’s low after every transmission, ~OE is just high, clock and data just transfer the data. Sometimes when the H8S gets an interupt the Clock pause for some time and continues with the data afterwards. The clock is around ~400kHz.

I confirmed the protocol via the oscilloscope, but still I don’t get any sign from the board. No fan, nothing else. There must be more than this single transmisison. Maybe the board is to much damaged. My modified board was already broken when I got it. There is a loose connection related to the cardbus. Maybe this is my problem I don’t know.

I’ve two board with two connectors for the PMH4 here. Why not using the OEM one as starter help for the other one?

t42 gives some starting help

I think the PMH4 does what it should do. The H8S has an digital-analog-converter pin connected to the video brightness. But I haven’t implemented it yet. But I don’t think the device booted, because neither the CPU nor the chipset produce any heat. Ok, maybe it does, I only used my finger as thermometer. A thermal camera would help here. I’ll borrow a thermal camera for that.

There are lot of pins which I ignore atm. E.g. A20 pin. Is there something to do in a specific time serie?

What’s next?

  • build a small protocol sniffer for the PMH4 XP using a msp430 or stellaris arm
  • make progress on the bootloader
  • find a way to flash back the OEM H8S firmware
  • find a way to flash my bootloader via OEM flash tools

My requirements to the bootloader are

  • UART flashing via XMODEM
  • a simple UART shell
  • I2C as recovery and shell as well

I2C pins are a lot easier to find and modify than the H8S UART. I’m not yet sure if the H8S should be the master or the slave and on what address he should use? Multiple? UART tx is working. Rx is a task to do.

PMH4 / PMH7 / Thinker communication

On newer board the PMH interfaces changed (>= x60, t60, …). They merge the LPC interface and the XP interface into an protocol over SPI. And the new PMH is used as GPIO expander as well.

pmh4 pmh7 thinker communication


[GSoC] EC/H8S firmware week #5

The T40 is flashing leds! The toolchain is still a little bit tricky. I’m using the debian package gcc-h8300-hms, written a small linker script and took the startup assembly routine from Johann Gysin’s led radiator.

Now I can flash leds. But what about booting the board? I would say it’s enough to put

  • (!MAINOFF) = high
  • FAN ON = high
  • pulse high on (!PWRSW_H8)

But it’s not enough. Also the FAN isn’t starting to rotate. I’ll try to debug every pin this week and solder some debug pins for the 2nd EC (PMHx) to the my modified T40 as well as to an unmodified T42p. The H8S is talking to the PMHx via SPI, while the H8S is the master and is doing bit banging SPI in software, because it doesn’t have a hardware unit for that. I’ll also use these pins for testing my SPI implementation. I’ll try to reuse an open source SPI implementation.

I also asked me if it’s a good idea to port coreboot for the T40 before continuing any efforts to the EC, but it’s a little bit harder, because the T40 uses a LPC/FWH flash in a TSOP40 case. Another option is changing the hardware to a board which is already supported by coreboot like a x60/t60 or x201. But it’s much more harder to access the 8 pins for flashing the EC on these boards.

Before switching to another board, the powersequencing must work and I need a robust recovery way, because when you kill the EC by flashing a new firmware, you don’t get a second chance, unless you solder a lot. Chrome EC fix this problem by splitting the EC firmware into 2 parts. One read-only part and one read-write’able part. Only the second part gets updated and the read-only part can at least boots the device.

Before starting the H8S port for Chrome EC I want to have a bootloader. Because it would improve developing speed. I think implement this is much faster than doing the full Chrome EC support and most of the bootloader code can be re-used for Chrome EC.

I’m also not perfectly sure Chrome EC is the best solution. It’s special use-case is EC, which is perfect. But neither the documentation (I think there is more than one page) nor the bugtracker is public. Thus it makes difficult to use. I’m also not sure if Chrome EC would apply my H8S port into their repository.

[GSoC] coreboot for ARM64 Qemu – Week #4 and #5

From this week I started dealing with the core aspects of aarch64 design. I continued with the process of building the armv8, along with handling the required patching-up, interfacing, hook-ups. In my last post, I had talked about the toolchain building error (in binutils) for arm64 which I was facing on OSX. I had to remove the –enable-gold flag from the binutils. After making this small update, the build_BINUTILS looked like this, and I was able to get the toolchain working.

build_BINUTILS() {
 if [ $TARGETARCH == "x86_64-elf" ]; then
 CC="$CC" ../binutils-${BINUTILS_VERSION}/configure --prefix=$TARGETDIR \
 --target=${TARGETARCH} --enable-targets=${TARGETARCH}${ADDITIONALTARGET} \
 --disable-werror --disable-nls --enable-lto \
 --enable-plugins --enable-multilibs CFLAGS="$HOSTCFLAGS" || touch .failed
 $MAKE $JOBS || touch .failed
 $MAKE install DESTDIR=$DESTDIR || touch .failed

The work had just began after fixing the toolchain. On attempting to building, the faced error I got was :

toolchain.inc:137: *** building bootblock without the required toolchain. Stop.

This was due to certain wrongly configured CONFIG options in the Kconfig. After this stage the initial bring-up of arm64 looked stable. Moving forward, I was met with an error in src/arch/arm64/c_entry.c

src/arch/arm64/c_entry.c: In function ‘arm64_init’: src/arch/arm64/c_entry.c:52:2: error: implicit declaration of function ‘cpu_set_bsp’ [-Werror=implicit-function-declaration] cpu_set_bsp();

The inclusion of necessary files and structures were correct, and I kept getting this error. Furquan ultimately pointed to change 257370  following which, I could get past this. After this, I had to solve another BSD/OSX issue about date in genbuild_h.sh to get my build progressing.

Subsequently, some architectural decisions had to be made for the armv8. In the initial version, I had been banking on cbfs_media based structure in media.c, for creating functions for read, write and map. But the older formulation (in cbfs_core.c and cbfs_core.h) is changed now. In order to keep up, and to maintain uniformity, we decided to handle this as it is handled in armv7, i.e by creating a mapping to the qemu memory mapped space. Another point of discussion for stage loading. It is being brought up similar to armv7 for now. This might change in the future. Also the organisation for UART was finalised. plo11.c is included, as in  src/drivers/uart/Makefile.inc. by setting the DRIVERS_UART_PL011 in armv8 Kconfig.

Next hitch was dealing with SMP. In my proposal, I had suggested that incorporating smp into the emulation could be a long term goal. But since smp is a part of core arm64 logic, this cannot be completely ignored at this stage. I am met with this

coreboot/src/arch/arm64/stage_entry.S:94: undefined reference to `smp_processor_id’
build/arch/arm64/c_entry.romstage.o: In function `seed_stack’:


A cpu file which adds smp_processor_id() is needed at this moment, which I am currently working on. Next week’s plan is to get past these (and meet new unforeseen issues 😛 ) and boot off on qemu.




[GSoC] End user flash tool – week #4 #5

Hello! During week #4 and #5 I worked on several cases:

  1. Integration of cbfs_tool features.
  2. Improving libflashrom querying functions / integrating already existing patches.
  3. Extending and improving GUI.
Integration of cbfs_tool features

cbfs_tool is bigger project than bios_extract, so I took a little more to integrate it than during bios_extract integration as I needed to do some investigation how it works. I imported code related to:

  • creating rom file
  • adding components like stage, payload, option rom, bootsplash etc.
  • printing rom content
  • deleting components.

The same like in case of libflashrom and bios_extract I created a static library and linked it with flash tool.

IMPROVING LIBFLASHROM querying functions / integrating patches

After posting my draft patch for initial review on flashrom mailing list I got great feedback which helped me a lot. Urja Rannikko and Stefan Tauner pointed my mistakes and proposed improvements, moreover Anton Kochkov shared his libflashrom changes where he worked on similiar issues.  This community is really helpful. Thanks!

So, I did improvements in querying functions. Currently we have:

const char** fl_supported_programmers(void);
const char* fl_version(void);
fl_flashchip_info *fl_supported_flash_chips(void);
fl_board_info *fl_supported_boards(void);
fl_chipset_info *fl_supported_chipsets(void);
int fl_supported_info_free(void *p);

Unnecessary functions which return number of supported hardware of certain type have been removed. Now we can call functions to allocate the table and get a pointer to it. Of course I will create a patch and post it for second review.

I had a problem as my SOIC clip did not arrive on time, I was not able to test operations related functions on my T60. Actually it was my fault because I have not noticed a comment on internet auction that it may go from China. I have been waiting for 3 weeks for its arrival. Now I already have it so my main focus this week is to test libflashrom on real hardware.

extending / improving gui

I extended a GUI part to allow user to manipulate with rom contents like adding payload, bootsplash etc. and also removing such components. Of course this is not a main purpose of my project. The main focus is to create a tool which will allow user to don’t care about which options are correct. I will be going in this direction, I want to automate a process of creating a coreboot image as much as possible. So currently this is a kind of ‘advanced mode’. I implemented it for several reasons:

  • after integration of bios_extract, cbfs_tool and libflashrom it was not big effort to do it
  • implementing and testing it helped me to better understand integrated code and its features
  • there are also advanced users who may want to do some manual changes

Tasks for current week:

  • test probing, reading, flashing with libflashrom on T60 (through linux_spi)
  • GUI improvements proposed by Stefan Tauner(searching, sorting and filtering in supported hardware screen)
  • code cleanup

[GSoC] EC/H8S firmware week #3|4

In the last 2 weeks I managed to flash the H8S on the T40 using the OEM Renesas Flash Tool including their flash application. Flashing works in 2 steps, first upload a flash application into the H8S. Second this flash application will receive the firmware (via serial) and write it into the flash. Thanks to Renesas this application is available in source code. I would like to write an own flasher later.

But I wasn’t able to create a proper application yet. I could write the led programm in assembly, but having a working c compile is needed anyway.

I built a toolchain with gcc 4.9.2. The toolchain buildscript is very simple and can be found on github. I stopped my building efforts for now (building one based on gcc 4.4.6). There’s also a debian package for h8300 (based on gcc 3.4.6) which may be a good alternative. Before continuing in building toolchains and my led application, I’m reading me into linkerscipts and take a look how the compiler is working (e.g. what must a crt0 do?).

At the moment I know how the application should be compiled, where the reset vectors are and where the entrypoint. But putting these things together into a binary image is my task now.

The dev board I mentioned in my last post was stuck by the german post for the last 2 weeks, because there were on strike. The board is now in the custom office and I’ll collect in the next days, which will takes severals hours in Berlin.

[GSoC] coreboot for ARM64 Qemu – Week #3

For the week 3, I started to build the coreboot image to run on the target arm64 qemu. As soon as I started, I had to face a big red flag, a toolchain building error! The new toolchain (v1.31) failed to build on MacOSX. Despite several attempts, binutils failed to build and I couldn’t get the toolchain running. /buildgcc also failed on OSX due to missing string search for clang. Marc kindly help me out on this by introducing a small patch on this front. I also tried using the actual gcc and g++ (and not the innate gcc and g++ on OSX which are just symlinks to clang) but couldn’t rectify the toolchain build error.  But strangely, when I tried to build an older toolchain (v1.24) on the same machine, it worked. Confused, I decided to move forward with the build with the old toolchain itself.

I had to make some modifications on the src/mainboard/emulation/Kconfig, to bring up the new emulation mainboard. After this, I was able to successfully generate a configuration by running make menuconfig.

Next step was to make and generate the build/coreboot.rom. I have been facing some errors while building which I have been resolving on the way. The plan for this week is to finish the build. I also want to look at solving the toolchain building issue. Stepan said that the new toolchain hasn’t been tested on OSX, so this should provide some useful insights.

[GSoC] Thinking about Logging

Hey coreboot community!

It’s been just under a month of working on coreboot. I’ve not been keeping up with my blog posts. So here is the first of three particularly long posts detailing what I’ve been up to, what decisions I’ve been making, and what problems I’ve faced. This post is a background on logging, the problems it has as of now, and how not to fix them.

Tomorrow I will be posting a blog post giving some background on a change I made to solve these problems in a fair way. I will also be posting a blog post about what’s up next for me.

So how does logging work?

For most programs, logging works simply through slinging text at some interface. A developer wanting to leak some information uses a function to print some information. You can then look at stdout/stderr, or an output file, or syslog, or whatever, and get that leaked run-time information.

Where coreboot differs from most programs is that coreboot is pre-OS. The abstractions that our operating systems provide aren’t available for coreboot, and not just the higher abstractions like syslog. Coreboot is self contained. Where a Hello World using stdio might be something like:

fprintf(stdout, "Hello World\n")

coreboot doesn’t have that privilege. In theory, we could provide all the same familiar functions, but why? We really don’t need them. This information ultimately ends up going out on some UART, so why bother with needless abstractions? We’re constrained to fitting coreboot and a payload and a video option rom and a TXE and so on into 8MB or less… It’s important that we are prudent in what we make available.

So what does the coreboot project do? We have printk(), which you might associate with the linux kernel (‘print kernel’). In fact, this is exactly the case. If you go into src/console/printk.c, you’ll see a humorous message in the copyright notice:

* blatantly copied from linux/kernel/printk.c
* Copyright (C) 1991, 1992 Linus Torvalds

Why? Recall that coreboot used to be linuxbios, and linuxbios was largely an effort to bootstrap linux. For a really awesome background on coreboot and its origins, and particularly for an interesting look at just how much coreboot has changed over time, you might be interested in watching the first few minutes of this video

But just because we’re inspired by linux doesn’t mean we’re inside linux. In spite of the copyright, coreboot’s printk() does not resemble linux at all anymore besides in name. We’re fully responsible for this function, so how does it work?

Let’s follow a debugging print statement, for example, one at src/lib/cbfs.c:102

DEBUG("Checking offset %zx\n", offset);

Already we have something interesting. What’s 'DEBUG()'? I thought it was printk()?

Go to the top of the file and you’ll see some preprocessor

#define DEBUG(x...) printk(BIOS_SPEW, "CBFS: " x)
#define DEBUG(x...)

Oh, okay. So depending on DEBUG_CBFS, the above DEBUG() call either means an empty statement, or

printk(BIOS_SPEW, "CBFS: " "Checking offset %zx\n", offset);

Firstly, what’s a 'BIOS_SPEW'? Just a constant, as defined in src/include/console/loglevels.h. You’ll notice again that these loglevels mirror the linux loglevels exactly, replacing 'KERNEL_' with 'BIOS_'.

What’s the point of it? If you want to control the verbosity of your logs, you set CONFIG_DEFAULT_CONSOLE_LOGLEVEL to the loglevel you want and you’ll get more or less verbosity as a result. If your configured log level is greater than the loglevel the printk statement is tagged with, it prints.

Why is this file doing this alias of printk? Is it done elsewhere? Why is there a separate CONFIG_DEBUG_CBFS variable? I’ll get to that in a second. This is actually some of the problem I’m setting out to fix. For now, let’s continue by assuming that our configuration is set such that it expands out to printk. Where, then, is printk defined?

Go into src/include/console/console.h and you’ll see what printk() is about:

static inline void printk(int LEVEL, const char *fmt, ...) {}


#define printk(LEVEL, fmt, args...) \
do { do_printk(LEVEL, fmt, ##args); } while(0)

Hmm, why the wrapper with preprocessor? If we are producing a final version of coreboot to go into a production setting, there’s an advantage to muting the logging information at compile time, because at aggregate, debugging statements do have a meaningful performance penalty, and we can increase the speed of our boot by making them empty statements.

So it’s really do_printk. It comes from src/console/printk.c. I won’t post the full contents, but I’ll explain briefly what it does:

  1. checks LEVEL with the configured log level, muting statements if they’re more verbose than what is requested
  2. when configured as such, in pre-ram settings, mute statements not originating from the bootstrap processor.
  3. Temporarily stop function tracing (a configuration option to watch functions and their callsites)
  4. temporarily lock the console resources to the a single thread, ensuring writes do not overlap.
  5. deal with varargs loading into its type via va_start().
    (notice the 'args...' in the signature? That allows printk to take
    a flexible amount of variables. It places n arguments onto the stack
    and so that they can be popped off later. Functions interact with
    variable arguments via va_arg().)
  6. calls vtxprintf with wrap_putchar, the format string, the variable argument list, and NULL. This interpolates the varargs into the format string and pushes it to the outputs.
  7. clean up variable arguments with va_end()
  8. flush the tx (not all output methods require it, but it’s harmless in those cases)
  9. Unlock the console resources
  10. re-enable tracing
  11. return the number of bytes of the output.

One cool thing to take away from this is how we abstract the factor of where console output is going from do_printk. wrap_putchar is another (aptly named) wrapper for do_putchar. do_putchar calls src/console/console.c‘s console_tx_byte(), which contains a bunch of functions like '__uart_tx_byte()' or '__usb_tx_byte()' or '__cbmemc_tx_byte()' which might be defined or left empty via preprocessor.

This allows us to not have to consider their differences or implementation in do_printk(), just in configuration and in their own implementations of init(), tx_byte(), and tx_flush()

The entirety of that is interesting, which is why I wanted to talk about it, but it’s not what I’m touching. Now we know how logging works, we know where we can influence it in do_printk(), and we’ve seen that it’s influenced elsewhere in preprocessor, too.

Let’s go back to the proprocessor 'DEBUG()' in src/lib/cbfs.c

#define DEBUG(x...) printk(BIOS_SPEW, "CBFS: " x)
#define DEBUG(x...)

If loglevels control verbosity, why are there additional CONFIG_DEBUG_CBFS variables? The gist of it is that mapping all statements to a level of 1-8 really isn’t granular enough for coreboot anymore. Sometimes you want to see most everything, but you’re not working on changes for CBFS and don’t need to see it dump its tables. Other times you’re working on a bug in CBFS and need all the information you can get, so you set the variable and get more output.

CONFIG_DEBUG_CBFS is not the only variable like this, nor should it be. There’s many different parts of coreboot, some are relevant all the time in your console output, some are rarely relevant, some are relevant when you need them to be, and if we can get more granularity without it being at the expense of performance or of making a complex mess, we should do it.

But there’s more than just CBFS and SMM and the things already defined with CONFIG_DEBUG_* variables. What that means is this will require quite a bit of grokking the source of coreboot, and classifying things. (Can we do this in a programmatic way?)

The first way I tackled this problem was to think about loglevels. What did they mean? The descriptions we had in the header were the same as those in the linux kernel:

#define KERN_EMERG "<0>" /* system is unusable*/
#define KERN_ALERT "<1>" /* action must be taken immediately*/
#define KERN_CRIT "<2>" /* critical conditions*/
#define KERN_ERR "<3>" /* error conditions*/
#define KERN_WARNING "<4>" /* warning conditions*/
#define KERN_NOTICE "<5>" /* normal but significant condition*/
#define KERN_INFO "<6>" /* informational*/
#define KERN_DEBUG "<7>" /* debug-level messages*/

I think this is poorly defined, particularly for coreboot. What’s the difference between a “normal but significant condition” and an “informational” message? What’s critical, what’s an error? In the context of the linux kernel these are clearly distinct but coreboot is do-or-die in a lot of cases. It stands to reason that a kernel can take many more steps than coreboot to recover.

I made a contribution to the header to try to define these in a more clear way. I didn’t get a whole lot of feedback, but it made it in. If you’re reading this and you didn’t see it, please look it over. If you think anything is wrong here, let’s fix it. I felt pretty confident that this mapped well to their current usage within coreboot.


But that’s really none of the battle. Shockingly, the granularity problem still exists even though I put some comments in a file!

My first thought was, “Well let’s just make a bunch of subsystems, each with their own loglevel 1-8. We can have a CBFS subsystem and an SMM subsystem and a POST code subsystem and so on.”

Let’s explore this idea now. I didn’t. I jumped in and implemented it and before thinking and realized some problems with this idea, quickly putting me back to square one.

When would a POST code qualify as BIOS_SPEW and when would it be BIOS_CRIT? It’s a laughable question. Some of these things are more fitting for toggle rather than a varying level of verbosity, and the current system for doing so is genuinely the best way to make decisions about printing such information… (Though, that doesn’t mean it’s implemented in the best way.)

Meanwhile CBFS probably does have enough of a variation that we can give it its own loglevels. But does it need to be mapped over 8 values? Maybe 4 would be more fitting.

So we want POST mapped to two values. We want CBFS mapped to 4. We want X mapped to N. How can we make a framework for this without creating a mess of Kconfig? How can we make sure that developers know what values they can use?

How are we going to do this in such a way that we don’t mess with preexisting systems? People can set their debug level in CMOS, how is this going to play into that system, where space is limited? We can’t afford to put unlimited configuration values into there. How are we going to do this in a way that extends printk, rather than re-implements it, without breaking everything that exists now? Remember above when I wondered about if other places do preprocessor definitions of printk like 'DEBUG()'? The answer is yes. Nearly everywhere.

It’s a problem of comparing of compile-time configuration against runtime configuration, of weighing preprocessor against implementing things in code, and of weighing simplicity against ease.

So in summation:

  • We need more granularity in logging. Right now we’re using putting the preprocessor to work to accomplish that, and while I first thought this was a bad practice, I came to feel feel that it actually isn’t so bad.
  • Outside of the additional variables to accomplish extra verbosity, there is little organization of printk statements besides by their log
    level. If log messages were properly tagged, logs would be much cleaner and easier to parse. This needs to be accomplished as well.
  • Logging works through a interface called do_printk(), which is separated out from the lower levels of printing, giving us a lot of freedom to work.
  • We must stay conscious of problems that we can introduce through creating too much new configuration.

Check in tomorrow for how I chose to solve this.

[GSoC] End user flash tool – week #3

During week 3 I worked on integrating bios_extract tool. I did analysis of code, understood it a bit and thought: “Nice, it should be fast and easy, I just need to do few changes”. Was it? Not completely.

After my analysis I knew that I need to do three things:

  • change main function to a function which I could invoke from GUI
  • redirect logs to GUI
  • make it possible to select output directory for extracted individual modules

I implemented it and decided that best solution will be to pack object files to static library. I compiled it and linked with my app, then I tried to extract a BIOS image and – BAM! – segmentation fault. Hmm, I did not change anything in extraction logic, so where I messed up? I started reverting my changes – segfault, segfault, segfault. I reverted almost all changes – still segfault. I downloaded bios_extract again and tried to first create object files from unchanged code, then build standard bios_extract app and apply my changes one by one. I compiled without any changes, tried to run bios_extract and… segmentation fault. I tried to compile with provided Makefile – it worked. Whoops, I missed checking Makefile content. This caught my attention:

CFLAGS ?= -g -fpack-struct -Wall -O0

fpack-struct? What is this sorcery? I googled it. Aha! Got you! This compiler flag packs all structure members together without holes, so structure alignment is not applied. Now it was obvious why I had segmentation faults, even if code was the same it worked differently because of different spaces between structure members. From this moment it was fast and easy :)

So, bios_extract is already integrated, it is possible to select rom file, select output directory and extract submodules there. Of course bios_extract log output is redirected to GUI. This is good, I can use rest of the week to work on libflashrom, my SOIC clip did not arrive yet, so I am still not able to test operation related functions, but already have feedback about my modifications applied to previously existing libflashrom patch, so I can start improving it – big thanks for review!

[GSoC] coreboot for ARM64 Qemu – Week #2

I spent the previous week working on the architecture of the qemu port. I made an attempt to dive into the internals of memory mapping for armv8. And then formulated an initial memory map structure for the armv8 port. After that I moved into developing some code. The most challenging aspect of this was moving to and fro between the qemu-armv7 existing port and the foundation-armv8 patches (now depreciated) of chromium and extracting the required modifications. My current work is building on qemu-armv7  taking inspiration on some aspects from the foundation armv8 which cater to the alterations required for 64-bit.

I then moved onto developing the default mem_uart which would be used in our emulation. After writing up a backbone for this new port, Marc suggested I push to gerrit and seek some reviews on it there. This was an important change from the development strategy I followed last year, when I did all the development locally and then pushed the end results to gerrit. This year, I would be following a more dynamic approach, with a continuos review-and-modify development cycle.

My plan for this week involves starting to build the firmware written thus far. I will look to load the built firmware in qemu and try getting some output on the console and finally get qemu-debug up and running.