https://www.coreboot.org/api.php?action=feedcontributions&user=IanK&feedformat=atomcoreboot - User contributions [en]2024-03-28T09:34:29ZUser contributionsMediaWiki 1.40.0https://www.coreboot.org/index.php?title=Serial_console&diff=34927Serial console2018-05-13T19:00:33Z<p>IanK: spelling</p>
<hr />
<div>= Notes =<br />
Serial is the most supported console with regard to software, it is supported in coreboot,seabios,serialice,ipxe,memtest etc...<br />
<br />
Unfortunately it's not available on every hardware anymore, some recent devices like the Lenovo X201 or the Chromebook pixel lack a serial port.<br />
<br />
= Supported Serial Ports controllers =<br />
<br />
== SuperI/O with integrated UARTs ==<br />
<br />
coreboot supports a variety of SuperI/O chips with UART functionality. If your mainboard has a serial port built-in, you can use it with no or minimal changes.<br />
<br />
== PCIe/Mini PCIe based serial cards ==<br />
<br />
Experimental coreboot and libpayload support is available for the [http://us.startech.com/product/MPEX2S952-2-Port-RS232-Mini-PCI-Express-Serial-Card-with-16950-UART StarTech MPEX2S952] card. Those cards are available at [http://www.amazon.com/2-PORT-Mini-Pci-Express-Card/dp/B003OCRW1Q Amazon] for around 30 USD. In order to use the card for romstage debugging, minimal setup of the PCIe bridge and the MPEX2S952 have to be added to romstage.c, otherwise the card is only available after the resource allocator has been running.<br />
<br />
== USB to Serial Converters ==<br />
<br />
USB to serial converters are not supported by coreboot at this time.<br />
<br />
= Enabling Serial Console =<br />
<br />
In order to get '''serial console output''' from various components of your system special options may be needed. This page tries to give a short description of how to use these options.<br />
<br />
== coreboot ==<br />
<br />
In coreboot you have to set up serial console support during configuration. Enable Console--> Serial port console output.<br />
You will be able to choose the UART and baud rate settings in the same menu.<br />
<br />
== FILO ==<br />
<br />
FILO picks up coreboot's serial console configuration, if compiled with serial console support.<br />
<br />
== GRUB legacy ==<br />
<br />
In your '''boot/grub/menu.lst''' add the following:<br />
<br />
serial '''--unit=0''' --speed='''115200'''<br />
terminal --timeout=15 serial console<br />
<br />
Change '''--unit=0''' to '''--unit=1''' for the second serial port (COM2).<br />
<br />
== GRUB2 ==<br />
The usual way to get serial is to have the following in /etc/default/grub:<br />
GRUB_TERMINAL_INPUT="console serial"<br />
GRUB_TERMINAL_OUTPUT="console serial"<br />
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"<br />
But that depend on having console(and so graphics) working(if console fails serial isn't tried), so adding the following to the end of /etc/grub.d/40_custom<br />
serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1<br />
terminal_input --append serial<br />
terminal_output --append serial<br />
set timeout=1<br />
play 480 440 1<br />
<br />
Then regenrate the grub config:<br />
For debian, ubuntu, trisquel:<br />
sudo update-grub2<br />
for arch, parabola:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== Linux kernel command line ==<br />
<br />
Add<br />
<br />
console='''ttyS0,115200''' console=tty0<br />
<br />
to send debug output to both the serial console on COM1 '''and''' to VGA.<br />
<br />
if you use grub2 you can add it to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub<br />
<br />
Then regenrate the grub config:<br />
For debian, ubuntu, trisquel:<br />
sudo update-grub2<br />
for arch, parabola:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== Linux login prompt ==<br />
<br />
In '''/etc/inittab''' add/enable a line like this:<br />
<br />
T0:23:respawn:/sbin/getty -L '''ttyS0''' '''115200''' vt100<br />
<br />
Change '''ttyS0''' to '''ttyS1''' for COM2.<br />
<br />
<br />
=== ubuntu, trisquel based ===<br />
Create a file called /etc/init/ttyS0.conf containing the following:<br />
# ttyS0 - getty<br />
#<br />
# This service maintains a getty on ttyS0 from the point the system is<br />
# started until it is shut down again.<br />
<br />
start on stopped rc or RUNLEVEL=[2345]<br />
stop on runlevel [!2345]<br />
<br />
respawn<br />
exec /sbin/getty -L 115200 ttyS0 vt102<br />
<br />
Then do<br />
sudo start ttyS0<br />
<br />
= Hardware pinouts =<br />
<br />
=== Requirements ===<br />
{| class="wikitable" border="1"<br />
! Pin<br />
! Required for<br />
|-<br />
| Mainboard TX -> Your development laptop RX<br />
|<br />
* Getting the mainboard's coreboot logs in real time.<br />
|-<br />
| Mainboard RX <- Your development laptop TX<br />
|<br />
* gdb in coreboot(Also requires Mainboard TX)<br />
* Interacting with payloads, and what run after them, trough the serial console.<br />
|-<br />
|}<br />
<br />
=== DE-9 ===<br />
{| class="wikitable" border="1"<br />
!Pin<br />
!Function<br />
|-<br />
|1<br />
|DCD<br />
|-<br />
|2<br />
|RX<br />
|-<br />
|3<br />
|TX<br />
|-<br />
|4<br />
|DTR<br />
|-<br />
|5<br />
|GND<br />
|-<br />
|6<br />
|DSR<br />
|-<br />
|7<br />
|RTS<br />
|-<br />
|8<br />
|CTS<br />
|-<br />
|9<br />
|RI<br />
|-<br />
|}<br />
<br />
=== Standard 10 pins PC header (alternating pin numbers) ===<br />
{| class="wikitable" border="1"<br />
!Pin<br />
!Function<br />
|-<br />
|1<br />
|DCD<br />
|-<br />
|2<br />
|DSR<br />
|-<br />
|3<br />
|RXD<br />
|-<br />
|4<br />
|RTS<br />
|-<br />
|5<br />
|TXD<br />
|-<br />
|6<br />
|CTS<br />
|-<br />
|7<br />
|DTR<br />
|-<br />
|8<br />
|RI<br />
|-<br />
|9<br />
|GND<br />
|-<br />
|10<br />
|NC<br />
|-<br />
|}<br />
<br />
=== Non-standard "intel configuration" 10 pins header (1:1 pin numbers) ===<br />
{| class="wikitable" border="1"<br />
!Pin<br />
!Function<br />
|-<br />
|1<br />
|DCD<br />
|-<br />
|2<br />
|RXD<br />
|-<br />
|3<br />
|TXD<br />
|-<br />
|4<br />
|DTR<br />
|-<br />
|5<br />
|GND<br />
|-<br />
|6<br />
|DSR<br />
|-<br />
|7<br />
|RTS<br />
|-<br />
|8<br />
|CTS<br />
|-<br />
|9<br />
|RI<br />
|-<br />
|10<br />
|NC<br />
|-<br />
|}<br />
<br />
=== Tricks ===<br />
* If you short RX and TX pins, what you send to the serial port, will be sent back. That is very usefull for debugging and finding the right pins.<br />
* ground is easy to find since it's connected to ground, a multimeter can find it easily trough "beeping".<br />
* If you lack a multimeter and that you want to know if 2 pins are connected, for finding the serial port's ground pin for instance, assuming you already found RX and TX, you could connect RX and TX to the pins you want to checks, and then send some data trough the serial port, if you read it back, then the pins are connected together. Warning, don't do that with voltages that are not in then range of voltages of your serial port.<br />
<br />
= Null-modem cable =<br />
<br />
A so-called '''null-modem cable''' is used for transmitting the output from a serial coreboot (or GRUB- or Linux-) console to another computer where a terminal program (such as minicom) can be used to display/save the messages.<br />
<br />
<gallery><br />
Image:Null modem cable.jpg|A null-modem cable.<br />
</gallery><br />
<br />
= Serial terminal software =<br />
<br />
== picocom ==<br />
<br />
Picocom is a small yet effective serial terminal program.<br />
<br />
== minicom ==<br />
<br />
Minicom is not just a serial terminal. It was written long before the internet existed and electronic communication was only possible with a modem to a mailbox-computer. Minicom is written with the ncurses library and provides its magic via a text interface. Other than logging, it provides z-modem up- and download-capability. <br />
<br />
== CuteCom ==<br />
<br />
This is an easy to use serial-terminal-program which is even able to write all communication into a log-file. It needs a computer with installed Qt-libs.<br />
<br />
[[Image:CuteCom.png|thumb|left]]<br />
<br clear="all" /><br />
<br />
= See also =<br />
[[Console_and_outputs]]<br />
<br />
{{PD-self}}</div>IanKhttps://www.coreboot.org/index.php?title=Build_HOWTO&diff=34522Build HOWTO2018-04-29T00:44:05Z<p>IanK: expert mode was removed in 2015 commit fdbc1af5e2c43ef223cc11ff98ee970423ae7797</p>
<hr />
<div>[[File:Coreboot menuconfig.png|thumb|right|'''make menuconfig''' in coreboot]]<br />
<br />
This page describes how you can build a coreboot image for your specific mainboard.<br />
<br />
== Requirements ==<br />
<br />
* gcc / g++ / gnat (gcc-multilib is ideal, makes building payloads a lot easier)<br />
* make<br />
* cmake (if using clang/llvm)<br />
* ncurses-dev (for '''make menuconfig''')<br />
* iasl (for targets with ACPI support)<br />
* flex and bison (for regenerating parsers)<br />
<br />
Optional:<br />
* doxygen (for generating/viewing documentation)<br />
<br />
==== debian ====<br />
<pre>apt-get install git build-essential gnat flex bison libncurses5-dev wget zlib1g-dev</pre><br />
<br />
== Building a payload (Optional) ==<br />
<br />
The majority of the payloads supported by coreboot are built automatically once they are selected and configured as described in the next section.<br />
<br />
Most beginners want to use the default [[SeaBIOS]] payload. It runs Option ROMs, is able to discover boot devices and provides a very simple boot menu.<br />
<br />
If, however, you need to build a payload that is currently not included in the coreboot build system:<br />
<br />
*First you need to download the source code for the [[Payloads|payload]] of your choice and build it.<br />
<br />
*Each payload may have different build instructions and requirements, however most of the time a "make" command will suffice. Please check [[Payloads]] and the wiki page for the respective payload for details.<br />
<br />
*The result of this step should be an ELF file (e.g. filo.elf, or coreinfo.elf) which you can use with coreboot (see below).<br />
<br />
== Building coreboot ==<br />
<br />
First, get the latest coreboot version from [[Git|our git repository]]:<br />
<br />
$ '''git clone <nowiki>https://review.coreboot.org/coreboot</nowiki>'''<br />
$ '''cd coreboot'''<br />
$ '''git submodule update --init --checkout'''<br />
<br />
The last step is important! It checks out a sub-repository in the 3rdparty directory.<br />
<br />
It is worth checking the [[Supported Motherboards]] page to see if your mainboard is known to work with a particular version of coreboot. If your board is listed and you want to try a known-working version, click the "upstream tree" link to find the commit hash and then check it out in git:<br />
<br />
$ '''git checkout <hash>'''<br />
<br />
If you do this, run `git submodule update --checkout` again to make sure the 3rdparty modules are in sync with the sources.<br />
<br />
Once you have the desired sources (and 3rdparty modules, if needed) checked out, you can configure the build-time options of coreboot:<br />
<br />
$ '''make menuconfig'''<br />
<br />
OR<br />
<br />
$ '''make nconfig''' (easier to navigate, uses ncurses)<br />
<br />
In that menu (which may look familiar, as other projects such as the Linux kernel or busybox use the same system), select at least the following options:<br />
<br />
* Enter the '''Mainboard''' menu.<br />
** In '''Mainboard vendor''' select the vendor of your board.<br />
** In '''Mainboard model''' select your exact mainboard name.<br />
** In '''ROM chip size''' select the exact size of the flash ROM chip you want to flash the coreboot image on. (see output of <code>flashrom</code> command)<br />
<br />
More detailed example (generic) configuration (tweak accordingly):<br />
(note that this assumes presence of native graphics initialization on the given board, which is not universally available in coreboot)<br />
<br />
General / Use CMOS for configuration values = enable (CMOS defaults are located in your boards directory src/mainboard/OEM/MODEL/cmos.default)<br />
Mainboard / Mainboard vendor = Name of manufacturer<br />
Mainboard / Mainboard model = Model name<br />
Mainboard / ROM chip size = size of flash chip<br />
Chipset / Include CPU microcode in CBFS = Do not include microcode updates (NOTE: you probably want to enable it on some systems)<br />
Devices / Use native graphics initialization = enable (NOTE: not available on all systems)<br />
Display / Keep VESA framebuffer = disable (disable for text-mode graphics, enable for coreboot vesa framebuffer)<br />
Generic Drivers / USB 2.0 EHCI debug dongle support = Enable<br />
Generic Drivers / Enable early (pre-RAM) usbdebug = Enable<br />
Generic Drivers / Type of dongle = Net20DC or compatible<br />
Generic Drivers / Digitizer = Present<br />
Console / USB dongle console output = enable<br />
Payload / Add a payload = An ELF executable payload (change if you want a different payload)<br />
Payload / Payload path and filename = grub.elf (assumes building GRUB manually. Change this if you want a different payload)<br />
<br />
Now go back into Devices (only do this if you didn't enable native graphics initialization; NOTE: instructions for adding a vbios option rom are not mentioned in the above instructions):<br />
<br />
Devices / Run VGA Option ROMs = disable<br />
Devices / Run Option ROMs on PCI devices = disable<br />
<br />
<br />
=== Intel boards ===<br />
For Intel boards you have to provide files coreboot can't generate by itself:<br />
* [[Intel Flash Descriptor region]]<br />
* [[Intel Gigabit Ethernet firmware]]<br />
* [[Intel Management Engine]]<br />
<br />
Please have a look at [[Binary situation]] for a full overview.<br />
The files have to be extracted from your vendor bios.<br />
<br />
* Enter the '''Chipset''' menu<br />
** Do the following based on which blobs you have:<br />
** Untick '''Build with a fake IFD''' (descriptor.bin)<br />
** Tick '''Add gigabit ethernet firmware''' (gbe.bin)<br />
** Tick '''Add Intel Management Engine firmware''' (me.bin)<br />
<br />
=== AMD boards ===<br />
For AMD boards you may have to provide files coreboot can't generate by itself:<br />
* [[NIC firmware]]<br />
* [[AMD IMC]]<br />
* [[AMD XHCI]]<br />
* [[AMD PSP]] (AMD's ME analog)<br />
<br />
Please have a look at [[Binary situation]] for a full overview.<br />
The files have to be extracted from your vendor bios.<br />
<br />
=== Choose the payload ===<br />
Here's the full list of supported [[Payloads]].<br />
<br />
By default, the [[SeaBIOS]] payload will be downloaded and built during the coreboot build process.<br />
<br />
If you want to use another payload (ELF for example):<br />
<br />
* Enter the '''Payload''' menu.<br />
** Set the '''Add a payload''' option to '''An ELF executable payload'''.<br />
** Then, specify the file name and path to your payload file (which you built before).<br />
<br />
=== VGA support ===<br />
In order to see something on your screen the graphic card has to be initialized by the [[VGA BIOS]] which is actually an [[Option ROM]].<br />
<br />
[[VGA support]] is required for payloads such as GRUB or elf-memtest86+-5.01.<br />
<br />
It isn't required for operating systems such as GNU/Linux as it initializes the graphic card by itself.<br />
<br />
On some platforms there's support for [[native gfx init]]. A VGA BIOS isn't required.<br />
<br />
=== Security Notes ===<br />
<br />
On modern X86 CPU's Microcode updates are required for secure and proper CPU operation. Not including it for philosophical reasons is done at your own risk.<br />
<br />
As an example, the 33xx, 43xx and 63xx "Piledriver" AMD Opteron CPU's have a fatal NMI to gain root exploit in some versions of the onboard microcode that is easily performed with userspace tool.<br />
<br />
=== Compiling ===<br />
<br />
You also need to build the coreboot cross-compiler. This is to compile for the architecture of the platform you are building coreboot FOR, not the system you are building ON. For x86 systems, you currently would use the i386 cross-compiler, not the x64 version.<br />
<br />
You can see all of the options available by running 'make help':<br />
<br />
$ '''make help'''<br />
...<br />
*** Toolchain targets ***<br />
crossgcc - Build coreboot cross-compilers for all platforms<br />
crosstools - Build coreboot cross-compiler and GDB for all platforms<br />
crossgcc-clean - Remove all built coreboot cross-compilers<br />
iasl - Build coreboot IASL compiler (built by all cross targets)<br />
clang - Build coreboot clang compiler<br />
test-toolchain - Reports if toolchain components are out of date<br />
crossgcc-ARCH - Build cross-compiler for specific architecture<br />
crosstools-ARCH - Build cross-compiler with GDB for specific architecture<br />
ARCH can be "i386", "x64", "arm", "aarch64", "mips", "riscv", "power8", "nds32le"<br />
Use "make [target] CPUS=#" to build toolchain using multiple cores<br />
<br />
<br />
To build the cross-compilers for all architectures using 4 threads (This takes a LONG time):<br />
$ '''make crossgcc CPUS=4'''<br />
<br />
To build the cross-compiler for just the x86 architecture with just a single thread:<br />
$ '''make crossgcc-i386'''<br />
<br />
<br />
You can also invoke the cross compiler build script directly (in this example eight threads). But you probably don't want to, because the makefile builds other things you need too:<br />
<br />
$ '''util/crossgcc/buildgcc -j 8'''<br />
<br />
If something fails, the build should tell you what file to look in. You can also try to search for the relevant log (<code>find . -name '*.log' | xargs grep Error</code>) and examine last few lines of it.<br />
<br />
That's the bare minimum. Feel free to adjust the other settings to your needs (see [[Coreboot Options]] for the full list), then exit menuconfig and build the coreboot image:<br />
<br />
$ '''make'''<br />
<br />
The file '''build/coreboot.rom''' is your final coreboot image you can flash onto a ROM chip or add payloads to with cbfstool.<br />
<br />
== Compiling with Clang/LLVM ==<br />
<br />
We have been working on building coreboot with clang/llvm and it basically works.<br />
Remaining issues can be reported upstream and then block this meta bug here:<br />
<br />
[http://llvm.org/bugs/show_bug.cgi?id=21691 META Compiling the Coreboot with clang]<br />
<br />
The default and recommended flow is still to use crossgcc.<br />
<br />
== Known issues ==<br />
<br />
Make sure you really have all the requirements installed!<br />
<br />
With certain versions of the gcc/ld toolchain shipped in some Linux distributions, it's possible that you'll see the following error when building coreboot:<br />
<br />
src/arch/x86/coreboot_ram.ld:129 cannot move location counter backwards<br />
<br />
This is a known bug in those versions of the toolchain. Before sending a complaint message to our mailing list, please try to switch to our reference cross-compilation toolkit then recompile the sources. To switch to the cross-compiler just run<br />
<br />
$ '''make crossgcc'''<br />
<br />
Then remove the '''.xcompile''' file and retry the compilation process:<br />
<br />
$ '''rm .xcompile'''<br />
$ '''make'''<br />
<br />
== Development version ==<br />
<br />
If you want to contribute a patch or report an issue about coreboot, you will need to set up your environment for full development.<br />
<br />
You '''must''' run '''make crossgcc''' and rebuild coreboot before reporting an issue or contributing a patch.<br />
<br />
To get set up to submit a patch please run '''make gitconfig''', then [[Git|register with gerrit]].<br />
<br />
== Flashing coreboot ==<br />
<br />
You can [[flashing coreboot|flash]] the coreboot image on a flash ROM chip using either an external EEPROM-programmer or a mainboard using the [http://www.flashrom.org flashrom] user-space utility.</div>IanKhttps://www.coreboot.org/index.php?title=Build_HOWTO&diff=28699Build HOWTO2017-09-09T22:48:26Z<p>IanK: use x64 as an example as it's more common</p>
<hr />
<div>[[File:Coreboot menuconfig.png|thumb|right|'''make menuconfig''' in coreboot]]<br />
<br />
This page describes how you can build a coreboot image for your specific mainboard.<br />
<br />
== Requirements ==<br />
<br />
* gcc / g++ / gnat (gcc-multilib is ideal, makes building payloads a lot easier)<br />
* make<br />
* cmake (if using clang/llvm)<br />
* ncurses-dev (for '''make menuconfig''')<br />
* iasl (for targets with ACPI support)<br />
* flex and bison (for regenerating parsers)<br />
<br />
Optional:<br />
* doxygen (for generating/viewing documentation)<br />
<br />
==== debian ====<br />
<pre>apt-get install git build-essential gnat flex bison libncurses5-dev wget zlib1g-dev</pre><br />
<br />
== Building a payload (Optional) ==<br />
<br />
The majority of the payloads supported by coreboot are built automatically once they are selected and configured as described in the next section.<br />
<br />
Most beginners want to use the default [[SeaBIOS]] payload. It runs Option ROMs, is able to discover boot devices and provides a very simple boot menu.<br />
<br />
If, however, you need to build a payload that is currently not included in the coreboot build system:<br />
<br />
*First you need to download the source code for the [[Payloads|payload]] of your choice and build it.<br />
<br />
*Each payload may have different build instructions and requirements, however most of the time a "make" command will suffice. Please check [[Payloads]] and the wiki page for the respective payload for details.<br />
<br />
*The result of this step should be an ELF file (e.g. filo.elf, or coreinfo.elf) which you can use with coreboot (see below).<br />
<br />
== Building coreboot ==<br />
<br />
First, get the latest coreboot version from [[Git|our git repository]]:<br />
<br />
$ '''git clone <nowiki>https://review.coreboot.org/coreboot</nowiki>'''<br />
$ '''cd coreboot'''<br />
$ '''git submodule update --init --checkout'''<br />
<br />
The last step is important! It checks out a sub-repository in the 3rdparty directory.<br />
<br />
In the coreboot directory you can configure the build-time options of coreboot:<br />
<br />
$ '''make menuconfig'''<br />
<br />
OR<br />
<br />
$ '''make nconfig''' (easier to navigate, uses ncurses)<br />
<br />
In that menu (which may look familiar, as other projects such as the Linux kernel or busybox use the same system), select at least the following options:<br />
<br />
* Enter the '''Mainboard''' menu.<br />
** In '''Mainboard vendor''' select the vendor of your board.<br />
** In '''Mainboard model''' select your exact mainboard name.<br />
** In '''ROM chip size''' select the exact size of the flash ROM chip you want to flash the coreboot image on. (see output of <code>flashrom</code> command)<br />
<br />
More detailed example (generic) configuration (tweak accordingly):<br />
(note that this assumes presence of native graphics initialization on the given board, which is not universally available in coreboot)<br />
<br />
General setup / Expert mode = enable<br />
General / Use CMOS for configuration values = enable (CMOS defaults are located in your boards directory src/mainboard/OEM/MODEL/cmos.default)<br />
Mainboard / Mainboard vendor = Name of manufacturer<br />
Mainboard / Mainboard model = Model name<br />
Mainboard / ROM chip size = size of flash chip<br />
Chipset / Include CPU microcode in CBFS = Do not include microcode updates (NOTE: you probably want to enable it on some systems)<br />
Devices / Use native graphics initialization = enable (NOTE: not available on all systems)<br />
Display / Keep VESA framebuffer = disable (disable for text-mode graphics, enable for coreboot vesa framebuffer)<br />
Generic Drivers / USB 2.0 EHCI debug dongle support = Enable<br />
Generic Drivers / Enable early (pre-RAM) usbdebug = Enable<br />
Generic Drivers / Type of dongle = Net20DC or compatible<br />
Generic Drivers / Digitizer = Present<br />
Console / USB dongle console output = enable<br />
Payload / Add a payload = An ELF executable payload (change if you want a different payload)<br />
Payload / Payload path and filename = grub.elf (assumes building GRUB manually. Change this if you want a different payload)<br />
<br />
Now go back into Devices (only do this if you didn't enable native graphics initialization; NOTE: instructions for adding a vbios option rom are not mentioned in the above instructions):<br />
<br />
Devices / Run VGA Option ROMs = disable<br />
Devices / Run Option ROMs on PCI devices = disable<br />
<br />
<br />
=== Intel boards ===<br />
For Intel boards you have to provide files coreboot can't generate by itself:<br />
* [[Intel Flash Descriptor region]]<br />
* [[Intel Gigabit Ethernet firmware]]<br />
* [[Intel Management Engine]]<br />
<br />
Please have a look at [[Binary situation]] for a full overview.<br />
The files have to be extracted from your vendor bios.<br />
<br />
* Enter the '''Chipset''' menu<br />
** Do the following based on which blobs you have:<br />
** Untick '''Build with a fake IFD''' (descriptor.bin)<br />
** Tick '''Add gigabit ethernet firmware''' (gbe.bin)<br />
** Tick '''Add Intel Management Engine firmware''' (me.bin)<br />
<br />
=== AMD boards ===<br />
For AMD boards you may have to provide files coreboot can't generate by itself:<br />
* [[NIC firmware]]<br />
* [[AMD IMC]]<br />
* [[AMD XHCI]]<br />
* [[AMD PSP]] (AMD's ME analog)<br />
<br />
Please have a look at [[Binary situation]] for a full overview.<br />
The files have to be extracted from your vendor bios.<br />
<br />
=== Choose the payload ===<br />
Here's the full list of supported [[Payloads]].<br />
<br />
By default, the [[SeaBIOS]] payload will be downloaded and built during the coreboot build process.<br />
<br />
If you want to use another payload (ELF for example):<br />
<br />
* Enter the '''Payload''' menu.<br />
** Set the '''Add a payload''' option to '''An ELF executable payload'''.<br />
** Then, specify the file name and path to your payload file (which you built before).<br />
<br />
=== VGA support ===<br />
In order to see something on your screen the graphic card has to be initialized by the [[VGA BIOS]] which is actually an [[Option ROM]].<br />
<br />
[[VGA support]] is required for payloads such as GRUB or elf-memtest86+-5.01.<br />
<br />
It isn't required for operating systems such as GNU/Linux as it initializes the graphic card by itself.<br />
<br />
On some platforms there's support for [[native gfx init]]. A VGA BIOS isn't required.<br />
<br />
=== Security Notes ===<br />
<br />
On modern X86 CPU's Microcode updates are required for secure and proper CPU operation. Not including it for philosophical reasons is done at your own risk.<br />
<br />
As an example, the 33xx, 43xx and 63xx "Piledriver" AMD Opteron CPU's have a fatal NMI to gain root exploit in some versions of the onboard microcode that is easily performed with userspace tool.<br />
<br />
=== Compiling ===<br />
<br />
You also need to build the coreboot cross-compiler. This is to compile for the architecture of the platform you are building coreboot FOR, not the system you are building ON. For x86 systems, you currently would use the i386 cross-compiler, not the x64 version.<br />
<br />
You can see all of the options available by running 'make help':<br />
<br />
$ '''make help'''<br />
...<br />
*** Toolchain targets ***<br />
crossgcc - Build coreboot cross-compilers for all platforms<br />
crosstools - Build coreboot cross-compiler and GDB for all platforms<br />
crossgcc-clean - Remove all built coreboot cross-compilers<br />
iasl - Build coreboot IASL compiler (built by all cross targets)<br />
clang - Build coreboot clang compiler<br />
test-toolchain - Reports if toolchain components are out of date<br />
crossgcc-ARCH - Build cross-compiler for specific architecture<br />
crosstools-ARCH - Build cross-compiler with GDB for specific architecture<br />
ARCH can be "i386", "x64", "arm", "aarch64", "mips", "riscv", "power8", "nds32le"<br />
Use "make [target] CPUS=#" to build toolchain using multiple cores<br />
<br />
<br />
To build the cross-compilers for all architectures using 4 threads (This takes a LONG time):<br />
$ '''make crossgcc CPUS=4'''<br />
<br />
To build the cross-compiler for just the x86 architecture with just a single thread:<br />
$ '''make crossgcc-x64'''<br />
<br />
<br />
You can also invoke the cross compiler build script directly (in this example eight threads). But you probably don't want to, because the makefile builds other things you need too:<br />
<br />
$ '''util/crossgcc/buildgcc -j 8'''<br />
<br />
If something fails, the build should tell you what file to look in. You can also try to search for the relevant log (<code>find . -name '*.log' | xargs grep Error</code>) and examine last few lines of it.<br />
<br />
That's the bare minimum. Feel free to adjust the other settings to your needs (see [[Coreboot Options]] for the full list), then exit menuconfig and build the coreboot image:<br />
<br />
$ '''make'''<br />
<br />
The file '''build/coreboot.rom''' is your final coreboot image you can flash onto a ROM chip or add payloads to with cbfstool.<br />
<br />
== Compiling with Clang/LLVM ==<br />
<br />
We have been working on building coreboot with clang/llvm and it basically works.<br />
Remaining issues can be reported upstream and then block this meta bug here:<br />
<br />
[http://llvm.org/bugs/show_bug.cgi?id=21691 META Compiling the Coreboot with clang]<br />
<br />
The default and recommended flow is still to use crossgcc.<br />
<br />
== Known issues ==<br />
<br />
Make sure you really have all the requirements installed!<br />
<br />
With certain versions of the gcc/ld toolchain shipped in some Linux distributions, it's possible that you'll see the following error when building coreboot:<br />
<br />
src/arch/x86/coreboot_ram.ld:129 cannot move location counter backwards<br />
<br />
This is a known bug in those versions of the toolchain. Before sending a complaint message to our mailing list, please try to switch to our reference cross-compilation toolkit then recompile the sources. To switch to the cross-compiler just run<br />
<br />
$ '''make crossgcc'''<br />
<br />
Then remove the '''.xcompile''' file and retry the compilation process:<br />
<br />
$ '''rm .xcompile'''<br />
$ '''make'''<br />
<br />
== Development version ==<br />
<br />
If you want to contribute a patch or report an issue about coreboot, you will need to set up your environment for full development.<br />
<br />
You '''must''' run '''make crossgcc''' and rebuild coreboot before reporting an issue or contributing a patch.<br />
<br />
To get set up to submit a patch please run '''make gitconfig''', then [[Git|register with gerrit]].<br />
<br />
== Flashing coreboot ==<br />
<br />
You can [[flashing coreboot|flash]] the coreboot image on a flash ROM chip using either an external EEPROM-programmer or a mainboard using the [http://www.flashrom.org flashrom] user-space utility.</div>IanKhttps://www.coreboot.org/index.php?title=Build_HOWTO&diff=28698Build HOWTO2017-09-09T22:47:51Z<p>IanK: fix: build instructions imply buildgcc is equivalent when it's not</p>
<hr />
<div>[[File:Coreboot menuconfig.png|thumb|right|'''make menuconfig''' in coreboot]]<br />
<br />
This page describes how you can build a coreboot image for your specific mainboard.<br />
<br />
== Requirements ==<br />
<br />
* gcc / g++ / gnat (gcc-multilib is ideal, makes building payloads a lot easier)<br />
* make<br />
* cmake (if using clang/llvm)<br />
* ncurses-dev (for '''make menuconfig''')<br />
* iasl (for targets with ACPI support)<br />
* flex and bison (for regenerating parsers)<br />
<br />
Optional:<br />
* doxygen (for generating/viewing documentation)<br />
<br />
==== debian ====<br />
<pre>apt-get install git build-essential gnat flex bison libncurses5-dev wget zlib1g-dev</pre><br />
<br />
== Building a payload (Optional) ==<br />
<br />
The majority of the payloads supported by coreboot are built automatically once they are selected and configured as described in the next section.<br />
<br />
Most beginners want to use the default [[SeaBIOS]] payload. It runs Option ROMs, is able to discover boot devices and provides a very simple boot menu.<br />
<br />
If, however, you need to build a payload that is currently not included in the coreboot build system:<br />
<br />
*First you need to download the source code for the [[Payloads|payload]] of your choice and build it.<br />
<br />
*Each payload may have different build instructions and requirements, however most of the time a "make" command will suffice. Please check [[Payloads]] and the wiki page for the respective payload for details.<br />
<br />
*The result of this step should be an ELF file (e.g. filo.elf, or coreinfo.elf) which you can use with coreboot (see below).<br />
<br />
== Building coreboot ==<br />
<br />
First, get the latest coreboot version from [[Git|our git repository]]:<br />
<br />
$ '''git clone <nowiki>https://review.coreboot.org/coreboot</nowiki>'''<br />
$ '''cd coreboot'''<br />
$ '''git submodule update --init --checkout'''<br />
<br />
The last step is important! It checks out a sub-repository in the 3rdparty directory.<br />
<br />
In the coreboot directory you can configure the build-time options of coreboot:<br />
<br />
$ '''make menuconfig'''<br />
<br />
OR<br />
<br />
$ '''make nconfig''' (easier to navigate, uses ncurses)<br />
<br />
In that menu (which may look familiar, as other projects such as the Linux kernel or busybox use the same system), select at least the following options:<br />
<br />
* Enter the '''Mainboard''' menu.<br />
** In '''Mainboard vendor''' select the vendor of your board.<br />
** In '''Mainboard model''' select your exact mainboard name.<br />
** In '''ROM chip size''' select the exact size of the flash ROM chip you want to flash the coreboot image on. (see output of <code>flashrom</code> command)<br />
<br />
More detailed example (generic) configuration (tweak accordingly):<br />
(note that this assumes presence of native graphics initialization on the given board, which is not universally available in coreboot)<br />
<br />
General setup / Expert mode = enable<br />
General / Use CMOS for configuration values = enable (CMOS defaults are located in your boards directory src/mainboard/OEM/MODEL/cmos.default)<br />
Mainboard / Mainboard vendor = Name of manufacturer<br />
Mainboard / Mainboard model = Model name<br />
Mainboard / ROM chip size = size of flash chip<br />
Chipset / Include CPU microcode in CBFS = Do not include microcode updates (NOTE: you probably want to enable it on some systems)<br />
Devices / Use native graphics initialization = enable (NOTE: not available on all systems)<br />
Display / Keep VESA framebuffer = disable (disable for text-mode graphics, enable for coreboot vesa framebuffer)<br />
Generic Drivers / USB 2.0 EHCI debug dongle support = Enable<br />
Generic Drivers / Enable early (pre-RAM) usbdebug = Enable<br />
Generic Drivers / Type of dongle = Net20DC or compatible<br />
Generic Drivers / Digitizer = Present<br />
Console / USB dongle console output = enable<br />
Payload / Add a payload = An ELF executable payload (change if you want a different payload)<br />
Payload / Payload path and filename = grub.elf (assumes building GRUB manually. Change this if you want a different payload)<br />
<br />
Now go back into Devices (only do this if you didn't enable native graphics initialization; NOTE: instructions for adding a vbios option rom are not mentioned in the above instructions):<br />
<br />
Devices / Run VGA Option ROMs = disable<br />
Devices / Run Option ROMs on PCI devices = disable<br />
<br />
<br />
=== Intel boards ===<br />
For Intel boards you have to provide files coreboot can't generate by itself:<br />
* [[Intel Flash Descriptor region]]<br />
* [[Intel Gigabit Ethernet firmware]]<br />
* [[Intel Management Engine]]<br />
<br />
Please have a look at [[Binary situation]] for a full overview.<br />
The files have to be extracted from your vendor bios.<br />
<br />
* Enter the '''Chipset''' menu<br />
** Do the following based on which blobs you have:<br />
** Untick '''Build with a fake IFD''' (descriptor.bin)<br />
** Tick '''Add gigabit ethernet firmware''' (gbe.bin)<br />
** Tick '''Add Intel Management Engine firmware''' (me.bin)<br />
<br />
=== AMD boards ===<br />
For AMD boards you may have to provide files coreboot can't generate by itself:<br />
* [[NIC firmware]]<br />
* [[AMD IMC]]<br />
* [[AMD XHCI]]<br />
* [[AMD PSP]] (AMD's ME analog)<br />
<br />
Please have a look at [[Binary situation]] for a full overview.<br />
The files have to be extracted from your vendor bios.<br />
<br />
=== Choose the payload ===<br />
Here's the full list of supported [[Payloads]].<br />
<br />
By default, the [[SeaBIOS]] payload will be downloaded and built during the coreboot build process.<br />
<br />
If you want to use another payload (ELF for example):<br />
<br />
* Enter the '''Payload''' menu.<br />
** Set the '''Add a payload''' option to '''An ELF executable payload'''.<br />
** Then, specify the file name and path to your payload file (which you built before).<br />
<br />
=== VGA support ===<br />
In order to see something on your screen the graphic card has to be initialized by the [[VGA BIOS]] which is actually an [[Option ROM]].<br />
<br />
[[VGA support]] is required for payloads such as GRUB or elf-memtest86+-5.01.<br />
<br />
It isn't required for operating systems such as GNU/Linux as it initializes the graphic card by itself.<br />
<br />
On some platforms there's support for [[native gfx init]]. A VGA BIOS isn't required.<br />
<br />
=== Security Notes ===<br />
<br />
On modern X86 CPU's Microcode updates are required for secure and proper CPU operation. Not including it for philosophical reasons is done at your own risk.<br />
<br />
As an example, the 33xx, 43xx and 63xx "Piledriver" AMD Opteron CPU's have a fatal NMI to gain root exploit in some versions of the onboard microcode that is easily performed with userspace tool.<br />
<br />
=== Compiling ===<br />
<br />
You also need to build the coreboot cross-compiler. This is to compile for the architecture of the platform you are building coreboot FOR, not the system you are building ON. For x86 systems, you currently would use the i386 cross-compiler, not the x64 version.<br />
<br />
You can see all of the options available by running 'make help':<br />
<br />
$ '''make help'''<br />
...<br />
*** Toolchain targets ***<br />
crossgcc - Build coreboot cross-compilers for all platforms<br />
crosstools - Build coreboot cross-compiler and GDB for all platforms<br />
crossgcc-clean - Remove all built coreboot cross-compilers<br />
iasl - Build coreboot IASL compiler (built by all cross targets)<br />
clang - Build coreboot clang compiler<br />
test-toolchain - Reports if toolchain components are out of date<br />
crossgcc-ARCH - Build cross-compiler for specific architecture<br />
crosstools-ARCH - Build cross-compiler with GDB for specific architecture<br />
ARCH can be "i386", "x64", "arm", "aarch64", "mips", "riscv", "power8", "nds32le"<br />
Use "make [target] CPUS=#" to build toolchain using multiple cores<br />
<br />
<br />
To build the cross-compilers for all architectures using 4 threads (This takes a LONG time):<br />
$ '''make crossgcc CPUS=4'''<br />
<br />
To build the cross-compiler for just the x86 architecture with just a single thread:<br />
$ '''make crossgcc-i386'''<br />
<br />
<br />
You can also invoke the cross compiler build script directly (in this example eight threads). But you probably don't want to, because the makefile builds other things you need too:<br />
<br />
$ '''util/crossgcc/buildgcc -j 8'''<br />
<br />
If something fails, the build should tell you what file to look in. You can also try to search for the relevant log (<code>find . -name '*.log' | xargs grep Error</code>) and examine last few lines of it.<br />
<br />
That's the bare minimum. Feel free to adjust the other settings to your needs (see [[Coreboot Options]] for the full list), then exit menuconfig and build the coreboot image:<br />
<br />
$ '''make'''<br />
<br />
The file '''build/coreboot.rom''' is your final coreboot image you can flash onto a ROM chip or add payloads to with cbfstool.<br />
<br />
== Compiling with Clang/LLVM ==<br />
<br />
We have been working on building coreboot with clang/llvm and it basically works.<br />
Remaining issues can be reported upstream and then block this meta bug here:<br />
<br />
[http://llvm.org/bugs/show_bug.cgi?id=21691 META Compiling the Coreboot with clang]<br />
<br />
The default and recommended flow is still to use crossgcc.<br />
<br />
== Known issues ==<br />
<br />
Make sure you really have all the requirements installed!<br />
<br />
With certain versions of the gcc/ld toolchain shipped in some Linux distributions, it's possible that you'll see the following error when building coreboot:<br />
<br />
src/arch/x86/coreboot_ram.ld:129 cannot move location counter backwards<br />
<br />
This is a known bug in those versions of the toolchain. Before sending a complaint message to our mailing list, please try to switch to our reference cross-compilation toolkit then recompile the sources. To switch to the cross-compiler just run<br />
<br />
$ '''make crossgcc'''<br />
<br />
Then remove the '''.xcompile''' file and retry the compilation process:<br />
<br />
$ '''rm .xcompile'''<br />
$ '''make'''<br />
<br />
== Development version ==<br />
<br />
If you want to contribute a patch or report an issue about coreboot, you will need to set up your environment for full development.<br />
<br />
You '''must''' run '''make crossgcc''' and rebuild coreboot before reporting an issue or contributing a patch.<br />
<br />
To get set up to submit a patch please run '''make gitconfig''', then [[Git|register with gerrit]].<br />
<br />
== Flashing coreboot ==<br />
<br />
You can [[flashing coreboot|flash]] the coreboot image on a flash ROM chip using either an external EEPROM-programmer or a mainboard using the [http://www.flashrom.org flashrom] user-space utility.</div>IanKhttps://www.coreboot.org/index.php?title=BeagleBone_Black_-_screwdriver&diff=21953BeagleBone Black - screwdriver2016-11-05T12:41:33Z<p>IanK: Update to reflect a current bug.</p>
<hr />
<div>A tool for coreboot/libreboot/flashrom developers and users. The firmware itself is based on vanilla OpenWrt Chaos Calmer(15.04) with some modifications. This firmware is mainly intended for BeagleBone Black (BBB).<br />
<br />
<br />
== Installing screwdriver ==<br />
<br />
To install screwdriver on the BeagleBone Black you have to create a bootable memory with the screwdriver.<br />
In this example we use a Micro-SD card. The card should be at least 128MB big.<br />
<br />
<br />
1. Download recent screwdriver Version 0.3.0 from <br />
http://repo.fe80.eu/screwdriver/0.3.0/omap/generic/default/openwrt-0.3.0-omap-beagleboneblack-sdcard-vfat-am335x_evm.img<br />
(sha512sum: 685f72aaa14342c848f15c933ea4f80deb33cd3751457e3e19e3b101659d2b96bae7f7be33b542cfdc4750cdd27e7e47ce35ffba15a5c2e76f8c41e7aad05f69 )<br />
<br />
2. Insert the memory you want to install screwdriver on into your computer.<br />
<br />
Linux users can check the latest messages in <code>dmesg</code> and if the memory is listed as /dev/sdb this have to be used together with 'dd' for installation from inside the directory containing the downloaded .img file:<br />
<code>sudo dd if=openwrt-0.3.0-omap-beagleboneblack-sdcard-vfat-am335x_evm.img of=/dev/sdb bs=4M</code><br />
<br />
Windows users have to use additional software like 'Win32 Disk Imager' from here: https://sourceforge.net/projects/win32diskimager/<br />
<br />
3. Now you can insert the memory into your BeagleBone Black.<br />
<br />
<br />
== Starting screwdriver ==<br />
<br />
In most cases screwdriver boots automatically when the memory is inserted and then the power(external 5V power plug). If not there are three solutions: <br />
<br />
1) This should always work: Delete/wipe the internal memory of the BeagleBone black. This would force the BeagleBone Black to always boot from the memory you inserted.<br />
<br />
2) Pressing and holding every time the 'User Boot' button. This is the button next to the big, regular USB port.<br />
<br />
3) Rewrite internal memory to a recent official debian+u-boot image. It boots then automatically when you insert the screwdriver memory.<br />
<br />
== Basic usage ==<br />
<br />
There are two recommended ways to connect to the terminal of the screwdriver.<br />
<br />
First and always working: Use a USB to TTL (for example CP2104 for about 2$) adapter and connect it to the serial port of the BeagleBone Black.<br />
You have to use just 3 wires. Ground, TX and RX. Connect your ttl-adapter ground to serial pin 1 (the one with the white dot), RX to serial pin 4 and TX to serial pin 5.<br />
For the serial connection you can use for example <code>minicom -s</code>. In most cases on a linux machine the usb-ttl adapter gets: /dev/ttyUSB0 . The BeagleBone Black default serial speed is 115200.<br />
<br />
Second: Use a network cable and ssh. (This is not currently working. There is a [https://github.com/lynxis/bbb_screwdriver_builder/issues/13 bug to track this]). If it was working, there would be a dhcp server (192.168.1.1) running on the screwdriver. Log in as root with the password coreboot.<br />
<br />
== Using screwdriver for flashing SPI flash with flashrom ==<br />
<br />
screwdriver already have flashrom preinstalled and the BeagleBone Black have connectors you can flash SPI flash memory with.<br />
<br />
You can flash SPI flash chips that are not 'in-circuit' without the need of additional power source. The light 3,3V rail the BeagleBone Black delivers can power the SPI chip if you power up the BeagleBone Black with at least 5V 1,2A power supply over its round power connector.<br />
<br />
This is a good article with pictures how to wire the BeagleBone Black to a SPI flash chip: https://www.linux.com/learn/tutorials/746860-how-to-access-chips-over-the-spi-on-beaglebone-black/<br />
<br />
Connectors:<br />
<br />
{| class="wikitable"<br />
!|BeagleBoneBlack||Pin on P9(written next to the big connector board)||SPI||SPI SOIC8 Pin||SOIC16||CPU||DTS<br />
|-<br />
|I2C1_SCL||17||CS||1||7||A16||spi0_cs0<br />
|-<br />
|I2C1_SDA||18||MOSI||5||15||B16||spi0_d1<br />
|-<br />
|UART2_RXD||22||CLK||6||16||A17||spi0_sclk<br />
|-<br />
|UART2_TXD||21||MISO||2||8||B17||spi0_d0<br />
|-<br />
|GND||1 + 2||GND||4||10||GND||GND<br />
|-<br />
|VDD_3V3D||3 + 4||VCC||8||2||VDD_3V3D||VDD_3V3D<br />
|-<br />
|}<br />
<br />
After wiring everything up you can flash with this command:<br />
<code>flashrom -p linux_spi:dev=/dev/spidev1.0 -w yourfile</code> If you get the warning in flashrom that the flash chip is unsupported, you can force the flash with additional '-f' command and if everything worked fine, please directly report a logfile of the flash to the flashrom developers.<br />
<br />
<br />
<br />
== Using screwdriver as USB EHCI debugging tool ==<br />
<br />
The BeagleBone Black have a great free(as in freedom) and flexible architecture we can use for USB EHCI debugging. It have to be powered by external power supply over the round power connector.<br />
You need: mini-usb cable<br />
Connect the mini-usb cable to the EHCI debug port of your device you want to debug coreboot/libreboot on. If you are not sure what usb port is using ehci debug, you can just try all of them out.<br />
<br />
To run USB EHCI debugging you have to run:<br />
<code>screen /dev/ttyGS0</code><br />
<code>cat /dev/ttyGS0 | tee -a /tmp/output</code><br />
<br />
Then power on the target you want to debug and you would hopefully see the debug output.<br />
<br />
== Using screwdriver for flashing SPI flash with flashrom - IN-CIRCUIT ==<br />
<br />
=== Prerequisites ===<br />
We can flash an SPI flash chip in-circuit, providing we have an external power source.<br />
We will need<br />
* Power source for BeagleBone Black: USB (connected to computer or standard wall supply) or 5V barrel connector<br />
* Power source for SPI Flash chip, 3.3V. Ideally, we should use a lab Power Supply Unit as it is possible to vary the voltage easily and be sure we are getting the required voltage. It may not be possible to power the flash chip from the BeagleBone Black's 3.3V pin as it is too unreliable. Some guides also recommend an ATX PSU, but this may not be reliable, and at any rate it is good practice to check if the PSU is actually outputting 3.3V!<br />
* Ideally, a clip over the SPI chip, such as those sold by Pomona: http://uk.farnell.com/pomona/5252/test-clip-16-pos-1-27mm-soj-soic/dp/2406245. This clip is for SOIC-16 chips with 16 pins but other sizes are available e.g. for SOIC-8 chips. You should check what size your flash chip is by opening up the computer and identifying the chip. We can also solder the wires carefully, but the clip makes it easy to troubleshoot wiring issues. Other similar clips may work.<br />
* We should obtain wires. If we solder the flash chip the size doesn't matter, but we should use jumper cables for the SPI clip, with 2.54mm / 0.1" headers. Make sure to cut the wires as short as possible, less than 10cm, as interference may result in Flashrom not detecting the chip properly, or not at all.<br />
<br />
=== Wiring the flash chip to the BeagleBone Black and power supply ===<br />
<br />
Do not directly rest the BeagleBone Black on the computer motherboard which you are flashing, otherwise static electricity could damage components on the motherboard during flashing. <br />
<br />
These numbers correspond to pins on the BeagleBone:<br />
NC - - 21<br />
1 - - 17<br />
NC - - NC<br />
NC - - NC<br />
NC - - NC<br />
NC - - NC<br />
18 - - 3.3V (PSU)<br />
22 - - NC - pin 1 on flash chip<br />
<br />
Consult the BeagleBone documentation if you are unsure how the pins on the BeagleBone are numbered.<br />
Remember to connect pin 2 of the BeagleBone to the ground of the power supply.<br />
<br />
=== Testing connection ===<br />
<br />
<code>flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=128</code><br />
<br />
* Note that the SPI speed can be higher, if you want faster speeds. However, faster speeds are less stable. From experience, Flashrom sometimes doesn't detect the chip if there is too much interference, so a slower speed may be ideal. It may be possible to achieve over 512Hz as the SPI speed.<br />
* If Flashrom isn't sure what type of SPI chip you have after it detects the chip, you will need to open up the computer and look at what variation is printed on the chip. You will probably need a magnifying glass or microscope for this and some bright light. If you can't work it out, look on the internet and see what SPI chips your computer typically was manufactured with. You then specify with the -c option when you are using Flashrom to read or write the flash.<br />
<br />
=== Dump factory ROM image ===<br />
<br />
We should dump the factory ROM image in case the flashing process goes wrong somehow or the computer does not boot.<br />
<br />
<code>flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=128 -r factory.rom</code><br />
<br />
Now we verify the dumped image: <br />
<br />
<code>flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=128 --verify factory.rom</code><br />
<br />
You might want to do this multiple times too just to be sure that the dumped image was read correctly.<br />
<br />
=== Write your compiled image ===<br />
<br />
You will now send your compiled Coreboot ROM (or whatever ROM you're flashing to the SPI chip) to the BeagleBone, such as through scp. If you have connected through SSH this is easy.<br />
Assuming the ROM is called "rom.rom", run <br />
<code>flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=128 -w rom.rom -V</code> <br />
<br />
This may take a long time, especially at 128Hz. Experiment with higher SPI speeds to see how fast you can use Flashrom while achieving stability. For an 8k SPI chip it may take around 30 minutes at SPI speed of 128Hz.<br />
<br />
=== Further notes ===<br />
<br />
Some of this was copied from the Libreboot page on programming SPI chips with the BeagleBone Black: https://libreboot.org/docs/install/bbb_setup.html. This is a good resource, and it has further notes about achieving stability during flashing. There are also more images to illustrate setup.<br />
<br />
== older/outdated screwdriver versions ==<br />
<br />
Version 0.2: http://repo.fe80.eu/screwdriver/0.2/omap/generic/openwrt-0.2-omap-beagleboneblack-sdcard-vfat-am335x_evm.img<br />
sha512sum: 26fc145b4b43b2589d500429c3bba379612870a63c2c03388cd663345a7c3a0792efc97cf3546c1e53b5d7eb958d43b9d21a9d6d0e4f13dd03f29878ef8dc753<br />
<br />
== references ==<br />
<br />
The official screwdriver development repository: https://github.com/lynxis/bbb_screwdriver_builder<br />
<br />
1. how to wire spi chip: http://www.linux.com/learn/tutorials/746860-how-to-access-chips-over-the-spi-on-beaglebone-black/<br />
<br />
2. Beagle bone black shematics: https://raw.githubusercontent.com/CircuitCo/BeagleBone-Black/master/BBB_SRM.pdf<br />
<br />
3. BeagleBone CPU datasheet: http://www.ti.com/lit/ds/symlink/am3358.pdf<br />
<br />
4. am335x CPU technical reference: http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf</div>IanK