因為神經網路、深度學習之訓練資料集通常硬碟需求都很大，所以想要 USB Storage 開機哩！
瀏覽 PINE64 NOOB 文件時發現
Some of PINE64 devices, such as the Rock64 and SOPine, are equipped with SPI Flash. This allows users to flash u-boot onto the SPI and boot from an external USB 2.0 or USB 3.0 SSD/HDD/thumb-drive, thereby forgoing using eMMC or an microSD card.
To find out more about which images can used in conjunction for SPI booting please see ayufan’s github.
Writing u-boot to SPI Flash can be achieved in two ways:
Using a Stand-Alone Image to Write u-boot to SPI
This may be the simplest method of flashing u-boot to SPI. Download a dedicated image labelled u-boot-flash-spi.img.xz from ayufan’s github and flash it to a micro SD card, the same you would with any OS image (to learn how to flash OS images to micro SD please following steps outlined in Section 3.
Having flashed the image follow these steps:
- Insert the SD into the ROCK64
- Remove all other peripherals from the board
- Make sure that the eMMC module is disconnected from the board
- Apply power to the ROCK64
- Wait (few seconds) until the the LEDs on the board will blink continually
- Power off the board.
The board is now ready to boot from USB 2.0/3.0 storage.
Using a Script on Linux OS Images
Most of recent (newer than 0.6.9) Linux OS images contain a script called rock64_write_spi_flash.sh, which is found in /usr/local/sbin directory. To run the script you will first need to flash a Linux OS image to a micro SD card (to learn how to flash OS images to micro SD please following steps outlined in Section 3). Before proceeding make sure that the eMMC module is disconnected from the board. Once you have booted into Linux on your PINE64 device all you have to do is run the aforementioned script using this command:
sudo ./rock64_write_spi_flash.sh
Once the script finishes its operation, power off your board and remove the micro SD card. The board is now ready to boot from USB 2.0/3.0 storage.
Erasing and Rewriting SPI
There are two ways of removing u-boot from SPI. You can either download u-boot-flash-spi.img.xz from ayufan’s github or use a script found on Linux OS images titled:rock64_erase_spi_flash.sh. Follow the instructions in the previous sub-sections for the chosen method of removing u-boot from SPI; the instructions are are identical, as the process of erasing u-boot is the exact opposite of flashing it.
N.B. You can also erase SPI manually”. To do so, you need to download mtd-utils. on Debian or Ubuntu follow these instructions:
sudo apt-get install mtd-utils sudo flash_eraseall /dev/mtd0
Booting an OS image from USB 2.0/3.0 Storage
To boot and OS image from USB 2.0/3.0 Storage such as a SSD/HDD or a thumbdrive you first need to have u-boot written to your SPI flash. Please follow the instructions in the previous sub-sections to learn how to write u-boot to SPI on your PINE64 device.
Once you have u-boot on your SPI, the process off booting is very similar to booting from micro SD or eMMC.
- Download one of the supported OS images for your PINE64 device
- Flash the OS image to your USB 2.0/USB 3.0 storage device (to learn how to flash OS images please following steps outlined in Section 3 The instructions are identical for all types of storage, including USB 2.0/USB 3.0 HDDs and thumb-drives.)
- Insert the USB storage device with the flashed OS image into one of the USB ports on your PINE64 device
- Apply power
If you have followed all the steps correctly, the board should boot from your USB 2.0/3.0 storage device.
※ 註︰Armbian Debian Stetch 裡沒有︰
linux-build/u-boot-package/root/usr/local/sbin/
也確定了ROCK64 4G 版子上有 (5) 128 Mb SPI Flash ☺
同時仔細讀過
Here is a table show the detail what we may use in Rockchip platform, for 2 boot stage:
– use U-Boot SPL;
– use Rockchp idbLoader which is combinded by Rockchip ddr init bin and miniloader bin;
+--------+----------------+----------+-------------+---------+
| Boot | Terminology #1 | Actual | Rockchip | Image |
| stage | | program | Image | Location|
| number | | name | Name | (sector)|
+--------+----------------+----------+-------------+---------+
| 1 | Primary | ROM code | BootRom | |
| | Program | | | |
| | Loader | | | |
| | | | | |
| 2 | Secondary | U-Boot |idbloader.img| 0x40 | pre-loader
| | Program | TPL/SPL | | |
| | Loader (SPL) | | | |
| | | | | |
| 3 | - | U-Boot | u-boot.itb | 0x4000 | including u-boot and atf
| | | | uboot.img | | only used with miniloader
| | | | | |
| | | ATF/TEE | trust.img | 0x6000 | only used with miniloader
| | | | | |
| 4 | - | kernel | boot.img | 0x8000 |
| | | | | |
| 5 | - | rootfs | rootfs.img | 0x40000 |
+--------+----------------+----------+-------------+---------+
Then when we talking about boot from eMMC/SD/U-Disk/net, they are in different concept:
- Stage 1 is always in boot rom, it loads stage 2 and may load stage 3(when SPL_BACK_TO_BROM option enabled).
- Boot from SPI flash means firmware for stage 2 and 3(SPL and U-Boot only) in SPI flash and stage 4/5 in other place;
- Boot from eMMC means all the firmware(including stage 2, 3, 4, 5) in eMMC;
- Boot from SD card means all the firmware(including stage 2, 3, 4, 5) in SD card;
- Boot from U-Disk means firmware for stage 4 and 5(not including SPL and U-Boot) in Disk, optionally only including stage 5;
- Boot from net/tftp means firmeware for stage 4 and 5(not including SPL and U-Boot) on the network;
Boot Flow 1 is typical Rockchip boot flow with Rockchip miniloader;
Boot Flow 2 is used for most SoCs with U-Boot TPL for ddr init and SPL for trust(ATF/OP-TEE) load and run into next stage;
Note 1. If loader1 have more than 1 stage, program will back to bootrom and bootrom load and run into next stage. eg. If loader1 is tpl and spl, the bootrom will run into tpl first, tpl init ddr and back to bootrom, bootrom then load and run into spl.
Note 2. If trust is enabled, loader1 need to load both trust and u-boot, and then run into trust in secure mode(EL3 in armv8), trust do the initialize and run into U-Boot in non-secure mode(EL2 in armv8).
Note 3. For trust(in trust.img or u-boot.itb), armv7 has only one tee.bin with or without ta, armv8 has bl31.elf and option with bl32.
Note 4. In boot.img, content can be zImage and its dtb for Linux, and can optionally be grub.efi, and can be AOSP boot.img, ramdisk is option;
然後依言而行︰
Traditionally, booting Linux on the ROCK64 required an eMMC or microSD card, however it is now possible to boot withoutthose, assuming the SPI memory has been flashed. The ROCK64 contains an onboard 128Mbit SPI flash memory, which can be flashed with U-Boot in order to provide additional boot options:
- USB2 / USB3 drive
- PXE
- microSD
- eMMC
1. Write the U-Boot image
# From Linux or macOS
xz -k -d -c -v -T 3 u-boot-flash-spi.img.xz | dd of=/dev/<sdcard> bs=1M
Make sure you write to the correction location, it will destroy all data.
2. Boot the ROCK64
……
Boot order:
- SPI flash
- eMMC (disable with jumper)
- microSD
- USB drive
- PXE
───
幾秒後見著白色 LED 閃閃閃，卻遲遲等不到
SF: … bytes @ 0x8000 Written: OK
螢幕訊息☻
只得再讀新手文件，狐疑『閃閃閃』就是寫好了？
還好沒把 ROCK64 搞掛呦☆
rock64@rock64:~
rock64@rock64:~
the_phet 1 ●1 ●2
python3 Python 3.5.3 (default, Sep 27 2018, 17:25:39) [GCC 6.3.0 20170516] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> import cv2 >>> cap = cv2.VideoCapture(0) >>> while(True): ... ret, frame = cap.read() ... gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) ... cv2.imshow('frame',gray) ... if cv2.waitKey(1) & 0xFF == ord('q'): ... break ...
ls
input1::capslock input1::kana input1::scrolllock standby-led
input1::compose input1::numlock power-led usb-switch
rock64@rock64:/sys/class/leds
cat /sys/class/leds/{standby-led,power-led}/trigger
[none] rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock mmc0 mmc1 timer oneshot heartbeat default-on
[none] rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock mmc0 mmc1 timer oneshot heartbeat default-on
System information (version)
Detailed description
compile with GDB.
(process:24917): GStreamer-CRITICAL **: gst_element_get_state: assertion ‘GST_IS_ELEMENT (element)’ failed
ERROR! Unable to open camera
[Thread 0x7fffc5ec2700 (LWP 24921) exited]
[Inferior 1 (process 24917) exited with code 0377]
compile the videocapture_basic.cpp file using the following command.
OPENCV_LOG_LEVEL=DEBUG OPENCV_VIDEOIO_DEBUG=1 ./output[ INFO:0] VIDEOIO: Enabled backends(7, sorted by priority): FFMPEG(1000); GSTREAMER(990); V4L2(980); CV_IMAGES(970); CV_MJPEG(960); FIREWIRE(950); GPHOTO2(940)
[ WARN:0] VIDEOIO(createGStreamerCapture(filename)): trying …
(video_stream:17022): GStreamer-CRITICAL **: gst_element_get_state: assertion ‘GST_IS_ELEMENT (element)’ failed
[ WARN:0] VIDEOIO(createGStreamerCapture(filename)): result=(nil) isOpened=-1 …
terminate called after throwing an instance of ‘char const*’
Aborted (core dumped)
Steps to reproduce
After compiling the sample code in file opencv/samples/cpp/videocapture_basic.cpp changing line 28 and executing the output file getting the error
int apiID = cv::CAP_GSTREAMER