Emulating Exynos 4210 BootROM in QEMU

[…]This project allows to debug BootROM dynamically with GDB. It has been helpful for analyzing secure boot mechanism that loads and authenticates the next stage from flash memory.[…]

Nicely-written. Includes coverage of U-Boot and U-Boot Secure Boot.


Exynos 4 Dual 45nm

PS: I just learned about this blog. Catching up, there are some interesting older posts, eg:

Amlogic S905 SoC: bypassing the (not so) Secure Boot to dump the BootROM


Embedded Linux Japan Technical Jamboree 63 slides/videos uploaded

Status of Embedded Linux, Tim Bird
Review of ELC Europe 2017, Tim Bird
mplementing state-of-the-art U-Boot port, 2017 edition, by Marek Vasut
Linux カーネルのメモリ管理の闇をめぐる戦い(協力者募集中, Tetsuo Handa (NTT Data)
Request for your suggestions: How to Protect Data in eMMC on Embedded Devices, Gou Nakatsuka (Daikin)
Fuego Status and Roadmap, Tim Bird
Multicast Video-Streaming on Embedded Linux environment, Daichi Fukui (TOSHIBA)
From 1 to many Implementing SMP on OpenRISC, Stafford Horne
Core Partitioning Technique on Multicore Linux systems, Kouta Okamoto (TOSHIBA)
Debian + YoctoProject Based Projects: Collaboration Status, Kazuhiro Hayashi (TOSHIBA)


See-also: Septemer 2017 Jamboree 62:

Status of Embedded Linux, Tim Bird
EdgeX Foundry: Introduction and demonstration of end to end IoT system, Victor Duan, Linaro
Lighting Talk: Integration between GitLab and Fuego, Tomohito Esaki, IGEL Co., Ltd.
DebConf17 Report, Kazuhiro Hayashi, TOSHIBA
Lightning Talk : About the LTS now, Shinsuke kato, Panasonic Corporation
Kernel Recipes 2015 – Linux Stable Release process, Greg KH
Lightning Talk: IPv6 Ready Logo Test for LTSI 4.9 and introduction about CVE-2016-5863 and CVE-2017-11164, Fan Xin, Fujitsu Computer Technologies Limited



Environment variable whitelisting patch for U-Boot

Quentin Schulz of Free Electrons submitted a patch to U-Boot, adding whitelisting of variables, based on a patch by Maxim Ripard of Free Electrons.

[PATCH 00/11] Introduce variables whitelisting in environment

This patch series is based on a patch series from Maxime. This is an RFC. It’s been only tested in a specific use case on a custom i.MX6 board. It’s known to break compilation on a few boards. I have a use case where we want some variables from a first environment to be overriden by variables from a second environment. For example, we want to load variables from the default env (ENV_IS_NOWHERE) and then load only a handful of other variables from, e.g., NAND. In our use case, we basically can be sure that the default env in the U-Boot binary is secure but we want only a few variables to be modified, thus keeping control over the overall behaviour of U-Boot in secure mode. It works in that way:
– from highest to lowest priority, the first environment that can be loaded (that has successfully init and whose load function has returned no errors) will be the main environment,
– then, all the following environment that could be successfully loaded (same conditions as the main environment) are secondary environment. The env variables that are defined both in CONFIG_ENV_VAR_WHITELIST_LIST and in the secondary environments override the ones in the main environment,
– for saving, we save the whole environment to all environments available, be they main or secondary (it does not matter to save the whole environment on secondary environments as only the whitelisted variables will be overriden in the loading process

[1] https://patchwork.ozlabs.org/cover/842057/

For more info, see full email/patch on:


bootloader_instrumentation_suite – for u-boot

This test suite helps you keep track of different versions of u-boot/build tools, static analysis of that build’s binaries, and runtime trace results of running that binary on a given hardware configuration. For each u-boot/build configuration it keeps a database of information it statically gathered for each boot stage, boot stage images/ELF files, a prepared SD card image, and test results of runtime trace analyses. If it detects changes in the u-boot source or build tools it will create a new set of test result directories with a new sdcard image and static analysis results.[…]






Qualcomm seeks bootloader engineer

Embedded Software Engineer – Bootloaders
Qualcomm processors provide integrated solutions for millions of diverse mobile and new emerging platforms across IoT, Automotive and Compute markets. It all starts with the Boot Firmware the first mission critical code to execute on our SoC(System on chip) and prepare the system for operation. We design and develop the software we put in mask boot ROM, along with system boot-loaders. Features we work on include image authentication, multicore setup, the UEFI pre-boot environment, configuration of next-generation DDR memories, ARM CPU and custom Qualcomm DSP/microprocessors, MMU/Cache memory management and advanced driver development for multiple boot/storage devices including eMMC, UFS, NAND, SPI-NOR, QSPI and flashless boot transport interfaces such as PCIe, SDIO, USB. Embedded Bootloader design & development involves architecting solutions to address different use cases and feature requirements in the early bootloader environment before the handoff to the High Level Operating System kernel. Engineer is expected to work with different Qualcomm build infrastructure tools and ARM compiler tool chains to enable different drivers and services for Bootloaders, optimizing them both for boot time, internal memory size constraints and power metrics.
* Design, development and integration of custom and/or open source Bootloaders for QCT mobile platforms.
* ThreadX, Linux, Android, Windows Boot process knowhow
* UEFI (Unified Extensible Firmware Interface) based bootloader and device driver model experience
* coreboot, uboot based bootloader experiences




Microsoft seeks senior embedded Linux firmware engineer

The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services.
This role will be for a highly-motivated Firmware Engineer with a solid background in embedded system design using embedded Linux.
* 5+ years professional experience in one or many of: designing, developing embedded solutions using ARM SoCs and Linux, extensive u-boot customization, Linux kernel internals and adding new hardware drivers.
* 2+ years proven and demonstrable programming skill in C/C++ for resource constrained embedded platforms.
* Experience with debugging tools such as JTAG, oscilloscopes and bus analyzers.