diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 00000000..e69de29b diff --git a/404.html b/404.html new file mode 100644 index 00000000..7724153b --- /dev/null +++ b/404.html @@ -0,0 +1,1770 @@ + + + +
+ + + + + + + + + + + + + + +Slot | +Interfaces | +Use Cases | +
---|---|---|
J14 (mPCIe1) | +USB, PCIe, SIM | +LTE and Wifi modules | +
J13 (mPCIe2) | +USB, PCIe SIM | +LTE and Wifi modules | +
J12 (mSATA) | +mSATA | +only mSATA disks | +
Slot | +Interfaces | +Use Cases | +
---|---|---|
J16 (mPCIe1) | +USB, PCIe | +USB and Wifi modules | +
J15 (mPCIe2) | +USB, SIM1 | +only LTE modules | +
J14 (mSATA) | +mSATA, USB, SIM2 | +mSATA disks and LTE modules | +
Slot | +Interfaces | +Use Cases | +
---|---|---|
J15 (mPCIe1) | +USB, PCIe | +USB and Wifi modules | +
J14 (mPCIe2) | +USB, SIM1 | +only LTE modules | +
J13 (mSATA) | +mSATA, USB, SIM2 | +mSATA disks and LTE modules | +
This document describes a procedure of building a coreboot image for apu2 with +vboot support and measured boot utilizing a TPM module. Procedure will work +only on apu2 versions v4.9.0.6 and newer.
+Pull or build + docker container:
+docker pull pcengines/pce-fw-builder
+
Build v4.9.0.6 image:
+./build.sh release v4.9.0.6 apu2
+
Invoke distclean:
+./build.sh dev-build $PWD/release/coreboot apu2 distclean
+
Copy the vboot miniconfig:
+cp $PWD/release/coreboot/configs/config.pcengines_apu2_vboot $PWD/release/coreboot/.config
+
Create full config:
+./build.sh dev-build $PWD/release/coreboot apu2 olddefconfig
+
Build the image again:
+./build.sh dev-build $PWD/release/coreboot apu2 CPUS=$(nproc)
+
Flash the new image. The firmware image can be found in
+ release/coreboot/build
which is relative to cloned pce-fw-builder
+ directory.
The config file present in repository builds the binary with default vboot +developer keys. If one would like to use own keys, vboot has bash scripts that +simplify the key generation process.
+Enter previously cloned coreboot directory and change directory to vboot:
+cd $PWD/release/coreboot/3rdparty/vboot
+
Compile and install the vboot library (outside docker on the host):
+make
+DESTDIR=/usr sudo make install
+
Then invoke from $PWD/release/coreboot
:
3rdparty/vboot/scripts/keygeneration/create_new_keys.sh --4k --4k-root --output keys
+
This script will produce whole set of new random keys in the keys
directory.
+In order to use them, follow the procedure described previously, but:
Create full config:
+./build.sh dev-build $PWD/release/coreboot apu2 olddefconfig
+
Enter menuconfig:
+./build.sh dev-build $PWD/release/coreboot apu2 menuconfig
+
Enter Security -> Verified boot (vboot) -> Vboot keys. Change the directories:
+$(VBOOT_SOURCE)/tests/devkeys/some_key.vbpubk ----> $(top)/some_key.vbpubk
+
Do the change for all 4 key paths, but do not change the filename (generated + keys have the same names):
+($(VBOOT_SOURCE)/tests/devkeys/root_key.vbpubk) Root key (public)
+($(VBOOT_SOURCE)/tests/devkeys/recovery_key.vbpubk) Recovery key (public)
+($(VBOOT_SOURCE)/tests/devkeys/firmware_data_key.vbprivk) Firmware key (private)($(VBOOT_SOURCE)/tests/devkeys/kernel_subkey.vbpubk) Kernel subkey (public)
+($(VBOOT_SOURCE)/tests/devkeys/firmware.keyblock) Keyblock to use for the RW regions
+
Build the image again:
+./build.sh dev-build $PWD/release/coreboot apu2 CPUS=$(nproc)
+
Flash the new image. The firmware image can be found in
+ release/coreboot/build
which is relative to cloned pce-fw-builder
+ directory.
Flashmap layout.
+Whole flash is divided into sections describe in an FMD (FlashMap Descriptor)
+file (located in src/mainboard/pcengines/apu2
directory). Each section has
+strictly precised size. This allows to flash only certain flash regions with
+flashrom (requires quite fresh compilation of flashrom).
Flashing a single region, for example RW_SECTION_A:
+flashrom -p internal -w coreboot.rom --fmap -i RW_SECTION_A
+
++Region names are defined in the FMD file.
+
Verified boot
+Each boot component in firmware block A or B (depending which one is correctly +booting) is verified again the keys that signed the blocks and the root key +which public part lies in the recovery region. Only the firmware signed by the +keys that belong to the cryptographical keychain (established during key +generation) is allowed to boot. If the signatures are not matching, another +firmware slot is used (also must pass verification). If everything else fails, +boot from recovery. Recovery partition aka read-only is supposed to be +protected by SPI flash protection mechanism as it make the Root of Trust.
+++Note that firmware components signed by different keyset won't work. If You +change the keys, flash whole firmware.
+
Measured boot
+By utlizing TPM capabilities, each boot component is cryptographically measured +i.e. its hash is computed and extended in TPM's PCR (Platform Configuration +Register). The hash is not directly written into PCR, but extended, which means +that TPM takes current PCR value, add the hash value of the component and +rehashes the combined value. The final result is written to PCR. Such approach +has the advantage that the final PCR values after boot process is finished are +fixed. In other words, by measuring the same components, in same order, without +any changes in its content we are able to obtain same PCR values. There is no +other way to obtain the same result if any of the components changed, or if the +measuring order has been altered. Given that, the PCR values can clearly assure +that the firmware has not been tampered.
+In order to verify whether vboot and TPM works, one has to compile the cbmem +utility:
+cd $PWD/release/coreboot/util/cbmem
+make
+
And copy the cbmem executable to the apu2 platform booted with vboot support. +Dump the bootlog to a file:
+./cbmem -c > bootconsole.log
+
And analyze it. You should see similar messages:
+Phase 1
+FMAP: area GBB found @ 505000 (978944 bytes)
+VB2:vb2_check_recovery() Recovery reason from previous boot: 0x0 / 0x0
+Phase 2
+Phase 3
+FMAP: area GBB found @ 505000 (978944 bytes)
+FMAP: area VBLOCK_A found @ a0000 (65536 bytes)
+FMAP: area VBLOCK_A found @ a0000 (65536 bytes)
+VB2:vb2_verify_keyblock() Checking key block signature...
+FMAP: area VBLOCK_A found @ a0000 (65536 bytes)
+FMAP: area VBLOCK_A found @ a0000 (65536 bytes)
+VB2:vb2_verify_fw_preamble() Verifying preamble.
+Phase 4
+FMAP: area FW_MAIN_A found @ b0000 (2228160 bytes)
+VB2:vb2api_init_hash() HW crypto for hash_alg 2 not supported, using SW
+tlcl_extend: response is 0
+tlcl_extend: response is 0
+tlcl_lock_nv_write: response is 0
+Slot A is selected
+creating vboot_handoff structure
+
And the measurements made during boot process:
+ PCR-2 51d3adcb927807324651c102e5e07d8085b66bae944f37d4de3d89d6118a595f SHA256 [FMAP: COREBOOT CBFS: bootblock]
+ PCR-2 fd582fcb2af6ff4e703b2398df919f94c9c3bbcb675429a1414646d123ab141d SHA256 [FMAP: COREBOOT CBFS: fallback/romstage]
+ PCR-0 2547cc736e951fa4919853c43ae890861a3b3264 SHA1 [GBB flags]
+ PCR-1 a66c8c2cda246d332d0c2025b6266e1e23c89410051002f46bfad1c9265f43d0 SHA256 [GBB HWID]
+ PCR-2 a5e02cf99b58d52493d295dca701fdefe3cfc0afa901a70475c2de20603984e7 SHA256 [FMAP: FW_MAIN_A CBFS: fallback/ramstage]
+ PCR-3 269138dedbdc3d6d236212392fb18d29aefce116586c5f058419a214efa866a1 SHA256 [FMAP: FW_MAIN_A CBFS: bootorder]
+ PCR-3 269138dedbdc3d6d236212392fb18d29aefce116586c5f058419a214efa866a1 SHA256 [FMAP: FW_MAIN_A CBFS: bootorder]
+ PCR-3 269138dedbdc3d6d236212392fb18d29aefce116586c5f058419a214efa866a1 SHA256 [FMAP: FW_MAIN_A CBFS: bootorder]
+ PCR-2 6c1d20616d91442b61de89de6bf81f0ee8e929919c9284061e00d004de893994 SHA256 [FMAP: COREBOOT CBFS: spd.bin]
+ PCR-3 787ba3c5d060991254426794207f64eefe825f93cdebc00f24e7ca0f2acceae9 SHA256 [PSPDIR]
+ PCR-2 ca09ef53266de8a9f95a70b28279fdab4d8d21c48d12f6f20ebba9685adc2168 SHA256 [FMAP: COREBOOT CBFS: AGESA]
+ PCR-2 ca09ef53266de8a9f95a70b28279fdab4d8d21c48d12f6f20ebba9685adc2168 SHA256 [FMAP: COREBOOT CBFS: AGESA]
+ PCR-2 ca09ef53266de8a9f95a70b28279fdab4d8d21c48d12f6f20ebba9685adc2168 SHA256 [FMAP: COREBOOT CBFS: AGESA]
+ PCR-2 ca09ef53266de8a9f95a70b28279fdab4d8d21c48d12f6f20ebba9685adc2168 SHA256 [FMAP: COREBOOT CBFS: AGESA]
+ PCR-2 ca09ef53266de8a9f95a70b28279fdab4d8d21c48d12f6f20ebba9685adc2168 SHA256 [FMAP: COREBOOT CBFS: AGESA]
+ PCR-2 ca09ef53266de8a9f95a70b28279fdab4d8d21c48d12f6f20ebba9685adc2168 SHA256 [FMAP: COREBOOT CBFS: AGESA]
+ PCR-2 ca09ef53266de8a9f95a70b28279fdab4d8d21c48d12f6f20ebba9685adc2168 SHA256 [FMAP: COREBOOT CBFS: AGESA]
+ PCR-2 6f51a6e4ea6f26b2a5ae619421d0942515db9977c6136a4a6b3d2759b2616143 SHA256 [FMAP: FW_MAIN_A CBFS: fallback/dsdt.aml]
+ PCR-3 269138dedbdc3d6d236212392fb18d29aefce116586c5f058419a214efa866a1 SHA256 [FMAP: FW_MAIN_A CBFS: bootorder]
+ PCR-2 a6b195044628cf787c9006c3f8a520a0d3fce1df2566fa1ce0294ecc5daf0441 SHA256 [FMAP: FW_MAIN_A CBFS: fallback/payload]
+
++Some components are listed few times, because access to them is made several +times. Each time component is accessed from flash, it is measured.
+
As one can see the logs contain the PCR number that has been extended, the hash +value, used hashing algorithm and then the component name and location that the +measurement is corresponding to.
+The final PCR numbers can be checked with tpm2-tools
. It is pretty hard to
+compile them, so there is a prepared docker container that has already the
+tools compiled. Refer to 3mdeb/tpm2-tools-docker.
To check PCRs:
+docker run --privileged --rm -it 3mdeb/tpm2-tools-docker tpm2_pcrlist
+
Brief walkthrough APU2 and APU3 schematics show below difference:
+additional internal USB header
+power/reset/watchdog header changed
+Since coreboot v4.9.0.2 PC Engines firmware for apu2/3/4/5 has the Core +Performance Boost (aka CPU boost) enabled by default. The feature automatically +detects huge loads on the processor and temporarily raises the core frequency +to 1400MHz. More details how to check whether boost works available in the blog post
+Operating systems have problems with reporting the boosted frequency and +certain tricks have to be performed to reveal the true frequency of the +processor. Benchmarks and few utilities give the increased results, but the common frequency reading methods not.
+Check the frequency status on the system with:
+# sysctl dev.cpu.0
+dev.cpu.0.cx_method: C1/hlt C2/io
+dev.cpu.0.cx_usage_counters: 382 6500
+dev.cpu.0.cx_usage: 5.55% 94.44% last 28331us
+dev.cpu.0.cx_lowest: C2
+dev.cpu.0.cx_supported: C1/1/0 C2/2/400
+dev.cpu.0.freq_levels: 1000/924 800/760 600/571
+dev.cpu.0.freq: 600
+dev.cpu.0.%parent: acpi0
+dev.cpu.0.%pnpinfo: _HID=none _UID=0
+dev.cpu.0.%location: handle=\_PR_.P000
+dev.cpu.0.%driver: cpu
+dev.cpu.0.%desc: ACPI CPU
+
In order to notice the boosted frequency, one has to add:
+hint.p4tcc.0.disabled=1
+hint.acpi_throttle.0.disabled=1
+hint.acpi_perf.0.disabled=1
+
to boot/loader.conf
and reboot the platform.
After reboot, run some load generating task in the background like:
+# dd if=/dev/zero of=/dev/null count=4G &
+
Then read the CPU status again:
+# sysctl dev.cpu.0
+dev.cpu.0.cx_method: C1/hlt C2/io
+dev.cpu.0.cx_usage_counters: 291 3224
+dev.cpu.0.cx_usage: 8.27% 91.72% last 11496us
+dev.cpu.0.cx_lowest: C2
+dev.cpu.0.cx_supported: C1/1/0 C2/2/400
+dev.cpu.0.freq_levels: 1400/-1 1200/-1 1000/-1
+dev.cpu.0.freq: 1400
+dev.cpu.0.%parent: acpi0
+dev.cpu.0.%pnpinfo: _HID=none _UID=0
+dev.cpu.0.%location: handle=\_PR_.P000
+dev.cpu.0.%driver: cpu
+dev.cpu.0.%desc: ACPI CPU
+
Without running the task in background, frequency will be capped at 1400MHz:
+# sysctl dev.cpu.0
+dev.cpu.0.cx_method: C1/hlt C2/io
+dev.cpu.0.cx_usage_counters: 289 2606
+dev.cpu.0.cx_usage: 9.98% 90.01% last 18267us
+dev.cpu.0.cx_lowest: C2
+dev.cpu.0.cx_supported: C1/1/0 C2/2/400
+dev.cpu.0.freq_levels: 1400/-1 1200/-1 1000/-1
+dev.cpu.0.freq: 1000
+dev.cpu.0.%parent: acpi0
+dev.cpu.0.%pnpinfo: _HID=none _UID=0
+dev.cpu.0.%location: handle=\_PR_.P000
+dev.cpu.0.%driver: cpu
+dev.cpu.0.%desc: ACPI CPU
+
Currently there is no known method to show boosted frequency on Linux systems. Solution is work in progress.
+ + + + + + + + + + + + + +According to previous work on this issue ECC error injection fails due to +a range of memory that is used by APUs integrated graphics being excluded from +ECC support. This feature is controlled by a couple of registers, one of them is +D18F5x240, which has bit EccExclEn. This bit is set by AGESA as 1 soon after +memory training.
+Using version of AGESA that doesn't set mentioned bit results in working +ECC error injection in MemTest86 V7.4 Pro on apu2 and apu4:
+2018-09-25 16:59:03 - MtSupportRunAllTests - Injecting ECC error
+2018-09-25 16:59:03 - inject_amd64 - new nb_arr_add = 80000000
+2018-09-25 16:59:03 - inject_amd64 - new dram_ecc = 0012000F
+2018-09-25 16:59:03 - MCA NB Status High=00000000
+2018-09-25 16:59:03 - inject_amd64 - new nb_arr_add = 80000002
+2018-09-25 16:59:03 - inject_amd64 - new dram_ecc = 0012000F
+2018-09-25 16:59:03 - MCA NB Status High=00000000
+2018-09-25 16:59:03 - inject_amd64 - new nb_arr_add = 80000004
+2018-09-25 16:59:03 - inject_amd64 - new dram_ecc = 0012000F
+2018-09-25 16:59:03 - MCA NB Status High=00000000
+2018-09-25 16:59:03 - MtSupportRunAllTests - Setting random seed to 0x50415353
+2018-09-25 16:59:03 - MtSupportRunAllTests - Start time: 453 ms
+2018-09-25 16:59:03 - ReadMemoryRanges - Available Pages = 1035071
+2018-09-25 16:59:03 - MtSupportRunAllTests - Enabling memory cache for test
+2018-09-25 16:59:03 - MtSupportRunAllTests - Enabling memory cache complete
+2018-09-25 16:59:03 - Start memory range test (0x0 - 0x12F000000)
+2018-09-25 16:59:03 - Pre-allocating memory ranges >=16MB first...
+2018-09-25 16:59:04 - All memory ranges successfully locked
+2018-09-25 16:59:04 - MCA NB Status=846FC000F2080813
+2018-09-25 16:59:04 - MCA NB Address=00000000CFE528E0
+2018-09-25 16:59:04 - [MEM ERROR - ECC] Test: 3, Address: CFE528E0, ECC Corrected: yes, Syndrome: F2DF, Channel/Slot: N/A
+2018-09-25 17:00:08 - MCA NB Status=846FC000F2080813
+2018-09-25 17:00:08 - MCA NB Address=00000000CE3F46C0
+2018-09-25 17:00:08 - [MEM ERROR - ECC] Test: 3, Address: CE3F46C0, ECC Corrected: yes, Syndrome: F2DF, Channel/Slot: N/A
+
Configuration file used: +
TSTLIST=3,5,13
+NUMPASS=2
+
+DISABLEMP=1
+ECCPOLL=1
+ECCINJECT=1
+
+AUTOMODE=1
+SKIPSPLASH=1
+CONSOLEMODE=0
+
DISABLEMP
is set because of buggy multiprocessor support in UEFI. ECCPOLL
+enables checking for detected ECC errors after each test and ECCINJECT
enables
+ECC error injection on start of each test. The rest of options enables automode
+with report generation.
+On apu3 with 2GB RAM ECC isn't detected at all because of SPD which doesn't +report this feature.
+AGESA specification mentions +a build time option:
+++BLDCFG_UMA_ALLOCATION_MODE + Supply the UMA memory allocation mode build time customization, if any. + The default mode is Auto. + * UMA_NONE — no UMA memory will be allocated. + * UMA_SPECIFIED — up to the requested UMA memory will be allocated. + * UMA_AUTO — allocate the optimum UMA memory size for the platform.
+For APUs with integrated graphics, this will provide the optimum + UMA allocation for the platform and for other platforms will be the + same as NONE
+
There is also a runtime option UmaMode
in MemConfig
, which is parameter for
+AmdInitPost
, but it isn't clear if AGESA uses data received from host or changes
+it along the way before memory initialization. However, initial value of UmaMode
+already is UMA_NONE
, and neither changing it before calling AmdInitPost
nor
+in any callout functions doesn't change the outcome.
Clearing bit EccExclEn in register D18F5x240 from coreboot after it gets set by +AGESA seems to work as well. Description of this register in +BKDG, 52740 Rev 3.06 +informs that
+++BIOS must quiesce all other forms of DRAM traffic when configuring this range. +See MSRC001_001F[DisDramScrub].
+
Somewhere between memory training and setting UMA I receive
+WARNING Event: 04012200 Data: 0, 0, 0, 0
.
+From specification:
++MEM_WARNING_BANK_INTERLEAVING_NOT_ENABLED
+
I don't know if this is connected in any way to problems with ECC.
+Every corrected ECC error has the same syndrome - F2DF. It is caused by MemTest86
+setting D18F3xBC_x8 (DRAM ECC) to 0012000F
. More info about meaning of these is
+available in BKDG
+on pages 172-174 (ECC syndromes) and 456 (DRAM ECC register). Another register
+that is set by MemTest86 is D18F3xB8 (NB Array Address) as 8000000x
, where x
+is 0, 2 and 4.
On apu3 (4GB version) and apu5 register D18F3xB8 have some bits set on fields +marked as reserved in BKDG. After clearing these bits before starting MemTest86 +ECC injection started to work as expected on all platforms with ECC-capable memory.
+ + + + + + + + + + + + + +ttyUSB0
192.168.0.108
flashrom
Open APUx serial console. You can use minicom
to do that.
+ Parameters of connection:
sudo minicom -b 115200 -o -D /dev/<name of APUx serial console visible in PC>
+
E.g.
+sudo minicom -b 115200 -o -D /dev/ttyUSB0
Turn on APUx.
+When following communicate appears:
+Press F10 key now for boot menu, N for PXE boot
+
press N
to enter to the PXE boot menu.
---------------- iPXE boot menu ----------------
+ipxe shell
+autoboot
+
Select ipxe shell
. You have to hurry because default option is autoboot
and
+ it will be selected after few seconds.
After successful running the ipxe shell the following prompt will appear
+iPXE>
+
Now you have to type commands showed below:
+dhcp net1
+set filename pxelinux.0
+set next-server 192.168.0.108
+chain tftp://${next-server}/${filename}
+
++The
+X
number innetX
interface can be different depending on the connector +to which Ethernet is connected. If selected interface is connected to network +information similar to the showed below should appear:
Configuring (net1 00:0d:b9:47:bb:e1).................. ok
+
++MAC address should be displayed. If there is no MAC address that means that +there is no connection to the network for that interface.
+IP placed next to
+next-server
should be correct IP of used PXE server. +In case http server is used use http:// instead of tftp://
After few seconds PXE server boot menu should appear:
+ lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
+ x PXE server boot menu x
+ tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu
+ x Install x
+ x Debian-netboot x
+ x Voyage-netinst x
+ x x
+ x x
+ x x
+ x x
+ x x
+ x x
+ x x
+ x x
+ x x
+ mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
+
+ Press [Tab] to edit options
+
Select Debian-netboot
because it's the only OS with installed flashrom
+available in PXE server boot menu when instruction is being written. After that
+OS booting should start.
Number of OSes can be increased in the future.
+++When
+Legacy Console Redirection
is turned on displayed characters are +doubled. It's beacause iPXE is outputting data to the serial console and +to the screen, which is emulated on serial console.
When a prompt similar to the shown below appears:
+pcengines login:
+
Type root
as login. Then next prompt should appear:
Password:
+
Type root
as password to finish logging process.
++Steps shown above can be automated using Robot Framework.
+
Now you can start flashing process. To flash firmware with flashrom
usage
+ type:
flashrom -w <directory to ROM> -p internal -c "MX25L1605A/MX25L1606E/MX25L1608E"
+
flashrom -w <directory to ROM> -p internal
+
E.g. (APU2):
+flashrom -w /tmp/coreboot.rom -p internal
+
After correct firmware flashing the following message should appear:
+Reading old flash chip contents... done.
+Erasing and writing flash chip... Erase/write done.
+Verifying flash... VERIFIED.
+
Now you can reboot the platform.
+++Sometimes after APUx flashing platform doesn't turn on after warm boot. In +that situation cold boot is required.
+
scp
usageTo send ROM image to device you can use scp
.
cd <directory with ROM image>
+scp <ROM image> root@<IP of APUx to flash>:<directory to store ROM image on APUx>
+
E.g (APU2).:
+cd /home/me/coreboot/build
+scp coreboot.rom root@192.168.0.123:/tmp
+
Then to flash APU2 type in the serial console:
+cd
+flashrom -w /tmp/coreboot.rom -p internal
+
Turn on APUx.
+When the following prompt shows:
+Press F10 key now for boot menu
+
Press F10
.
Then menu similar to the showed below should appear:
+Select boot device:
+
+1. Payload [setup]
+2. Payload [memtest]
+
Select 1. Payload [setup]
by pressing 1
.
Next menu will be showed:
+### PC Engines apu2 setup v4.5.7 ###
+Boot order - type letter to move device to top.
+
+a USB 1 / USB 2 SS and HS
+b SDCARD
+c mSATA
+d SATA
+e mPCIe1 SATA1 and SATA2
+f iPXE (disabled)
+
+
+r Restore boot order defaults
+n Network/PXE boot - Currently Disabled
+u USB boot - Currently Enabled
+l Legacy console redirection - Currently Disabled
+w Enable BIOS write protect - Currently Disabled
+x Exit setup without save
+s Save configuration and exit
+
Select n Network/PXE boot - Currently Disabled
by pressing n
. This position
+should change to n Network/PXE boot - Currently Enabled
.
Now you can reboot platform by choosing s Save configuration and exit
, so
+ press s
to do that.
Details about building firmware are mentioned in README
+If You have already built an image with descriptions provided earlier, it is +time to connect RPi to apu.
+Prepare wire connections.
+pinout:
+Signal | +RPi Pin number | +APUx SPI pin header | +
---|---|---|
3V power | +17 | +1 VCC (may be omitted) | +
GND | +20 | +2 GND | +
SPI0 CS0 | +24 | +3 SPICS | +
SPI0 CLK | +23 | +4 SPICLK | +
SPI0 MISO | +21 | +5 SPIDI | +
SPI0 MOSI | +19 | +6 SPIDO | +
++Except that before flashing we have to make sure that APUx is on and + in S5 state. That means we have to connect pins 2 and 3 on J2 header + before turning power on. In such case there will be no output on serial + port.
+
Configure SPI and SSH on RPi.
+On RPi side we can use other pins as well. There are 2xSPI, 2x3V power and
+ 8xGND. Note that SPI requires dtoverlay=spi1-1cs
in /boot/config.txt
:
dtparam=spi=on
in boot/config.txt
,
+ reboot.wpa_supplicant.conf
+ /boot/
(/etc/wpa_supplicant/
should work as well)./etc/rc.local
): /etc/init.d/ssh start
+
~/img> sudo nmap -sP 192.168.0.255/24
+
+ [...]
+ Nmap scan report for 192.168.0.16
+ Host is up (0.17s latency).
+ MAC Address: B8:27:EB:24:81:58 (Raspberry Pi Foundation)
+ [...]
+
++Be carefull, you may need to adjust IP address mask!
+
ssh pi@192.168.0.16
+
pi@raspberrypi:~$ sudo apt-get install flashrom
+
##### APU1 +
pi@raspberrypi:~$ sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=16000 -r apu.rom -c "MX25L1605A/MX25L1606E/MX25L1608E"
+
##### APU2/3/4/5:
+ pi@raspberrypi:~$ sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=16000 -r apu.rom
+
Terminal command:
+sudo screen -L /dev/ttyUSB0 115200,-cstopb
+
{"use strict";/*!
+ * escape-html
+ * Copyright(c) 2012-2013 TJ Holowaychuk
+ * Copyright(c) 2015 Andreas Lubbe
+ * Copyright(c) 2015 Tiancheng "Timothy" Gu
+ * MIT Licensed
+ */var Wa=/["'&<>]/;Vn.exports=Ua;function Ua(e){var t=""+e,r=Wa.exec(t);if(!r)return t;var o,n="",i=0,s=0;for(i=r.index;i