reamond Posted January 10, 2017 Posted January 10, 2017 Hi, I am trying to make the OPI Zero boot with the help of the onboard SPI with the goal to boot from an usb drive and not from the sdcard. What steps should be executed. I only managed to get the Xenial image to work with my 512Mb board... so that is what I want to use. I assume... I need to make u-boot work with the sdcard... move the whole thing to the usb drive (with the u-boot) and than populate somehow the SPI with the image of an SPL, which would get it up through the u-boot on the usb. So I would need some in depth guidance (best would be some example commands to be used), what steps and tools should be executed to make it work. Thanks in advance & regards /R
martinayotte Posted January 10, 2017 Posted January 10, 2017 Well, there are several manual steps to accomplish that. First, you need to make sure the SPIDEV is enabled in DT, either in main DTB or by using DT Overlay. You need to grab "flashrom" sources, tweak the flashchip.c file for making sure the SPI transfer size ".page_size" is 64 for the chip you are using, then compile. Then, you are ready for Flash upload (adjust the 4096 according to your flash size) : dd if=/dev/zero count=4096 bs=1K | tr '\000' '\377' > spi.img dd if=/usr/lib/linux-u-boot-dev-orangepizero_5.24_armhf/u-boot-sunxi-with-spl.bin of=spi.img bs=1k conv=notrunc flashrom-0.9.9/flashrom -p linux_spi:dev=/dev/spidev0.0 -w spi.img In the future, we will probably provide a script that does all the tasks automatically.
zador.blood.stained Posted January 10, 2017 Posted January 10, 2017 @martinayotte This is not needed for the legacy kernel, flashrom works out of the box there, please keep in mind that we don't provide official images with the mainline for H3 devices yet. @reamond You'll need to transfer your system to a USB flash with a single ext4 partition (marked as bootable), copy the boot script to the root directory and adjust it to use USB instead of MMC. Then you'll need to get the latest u-boot (from the beta repository) and write it to the SPI flash. After that just hook up the serial console and check what works and what doesn't.
jernej Posted January 10, 2017 Posted January 10, 2017 I heard that capability for writing to SPI flash might be added to sunxi-fel so it will be even easier. I forgot what is the current state regarding this.
zador.blood.stained Posted January 10, 2017 Posted January 10, 2017 I heard that capability for writing to SPI flash might be added to sunxi-fel so it will be even easier. I forgot what is the current state regarding this. There are 2 experimental branches with SPI flash support: https://github.com/ssvb/sunxi-tools/tree/spiflash-a20-test https://github.com/ssvb/sunxi-tools/tree/20160523-spiflash-wip I don't see anything complicated for the SPI flash writing, apart from SPI transfer size limits in the mainline kernel, but this can be worked around and not directly related to SPI booting.
reamond Posted January 10, 2017 Author Posted January 10, 2017 Hi again, I am not on the top of my game so I need some further guidance. So if I got it right; 1, Move the partition and make it bootable (sounds ok) 2, Put u-boot on SPI, >> How can I do that? 3, Check with serial console what works >> How to check easy way? What are the key logs to check Can I do the check through SSL?
zador.blood.stained Posted January 10, 2017 Posted January 10, 2017 3, Check with serial console what works >> How to check easy way? What are the key logs to check First. Fot this kind of development and hacking serial console aka UART is mandatory. Nobody will want to play a guessing game if something doesn't work, so we need a boot log to figure out what happens during the boot process. 2, Put u-boot on SPI, >> How can I do that? From here: Assuming you booted a Xenial legacy image and installed flashrom (standard one from the Ubuntu repository) Assuming you extracted a .deb file from here and put u-boot-sunxi-with-spl.bin in your home directory Assuming SPI flash size is 16MBit dd if=/dev/zero of=flash.img bs=1M count=2 dd if=u-boot-sunxi-with-spl.bin of=flash.img conv=notrunc sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -w flash.img 1, Move the partition and make it bootable (sounds ok) You will also need to adjust and recompile the boot script (on the USB FS), at least replacing "mmc" with "usb" in load commands
ssvb Posted January 10, 2017 Posted January 10, 2017 I heard that capability for writing to SPI flash might be added to sunxi-fel so it will be even easier. I forgot what is the current state regarding this. Of course it works. And was working fine since the very beginning. You can find the detailed step by step instructions here: https://linux-sunxi.org/Bootable_SPI_flash#Using_the_sunxi-fel_tool Please note that the flashrom method is not very foolproof. The sunxi-fel tool may provide some nice high level features in the future. Such as the installed bootloader identification, extra checks if the old and new u-boot configurations are compatible, SPI speed tuning for faster boot (right now it is working at 6MHz in U-Boot) and maybe even larger SPL sizes via an additional loader stub. Not to mention that U-Boot may enforce write-protection for itself before passing control to the linux kernel (write-protection is enforced until the next power-down/power-up cycle), and in this case the flashrom tool will become completely useless. 1
jernej Posted January 10, 2017 Posted January 10, 2017 Of course it works. And was working fine since the very beginning. You can find the detailed step by step instructions here: https://linux-sunxi.org/Bootable_SPI_flash#Using_the_sunxi-fel_tool Great, I should check it before I made a post. A bit off topic, H5 support is marked as WIP. Any info on that? I see that H5 FEL support was added to sunxi-tools master. I tought that is enough?
ssvb Posted January 10, 2017 Posted January 10, 2017 H5 is still not supported in U-Boot, that's why it is WIP. The required changes are trivial though. The sunxi-fel tool (from my branch) has full H5 support. It is not merged to the upstream sunxi-tools because some code cleanups are necessary (in fact they are already done). And also it would be best to have a high level firmware upgrade functionality implemented rather than just raw read/write support. If this is inconvenient for you, then just let me know. In fact, I have added the basic flashrom information to the wiki page in order to discourage everyone from using it. How did it end up having the opposite effect?
jernej Posted January 10, 2017 Posted January 10, 2017 Ok, thanks for the explanation. How did it end up having the opposite effect? Probably nobody really checked the wiki. Maybe another important advantage of sunxi-fel method which I couldn't find mentioned on that page is that you don't need to fiddle with SD card images just to flash chip for the first time. Anyway, I'm convinced. Maybe this method just need some promotion on this and other forums along with the explanation why SPI NOR chip is a good thing.
zador.blood.stained Posted January 11, 2017 Posted January 11, 2017 Please note that the flashrom method is not very foolproof. The sunxi-fel tool may provide some nice high level features in the future. Such as the installed bootloader identification, extra checks if the old and new u-boot configurations are compatible, SPI speed tuning for faster boot (right now it is working at 6MHz in U-Boot) and maybe even larger SPL sizes via an additional loader stub. Not to mention that U-Boot may enforce write-protection for itself before passing control to the linux kernel (write-protection is enforced until the next power-down/power-up cycle), and in this case the flashrom tool will become completely useless. Fortunately for the current boards with SPi flash (Zero and PC2) SD slot has higher boot priority than SPI flash, so it's impossible to brick the device by writing an incompatible u-boot to the SPI flash (if you have physical access to the board). And main problem with Zero is its OTG port which serves as the main power input at the same time, so to reliably power the board for the FEL boot from a standard PC port you have to use microUSB Y-cable or power it through GPIO pins. In fact, I have added the basic flashrom information to the wiki page in order to discourage everyone from using it. How did it end up having the opposite effect? We are experimenting for now, and flashrom is convenient enough on the legacy kernel images since it works out of the box, doesn't require another PC, board or VM running Linux or compliing sunxi-tools for Windows (which may be a problem for an average user of this forum)
ssvb Posted January 11, 2017 Posted January 11, 2017 Fortunately for the current boards with SPi flash (Zero and PC2) SD slot has higher boot priority than SPI flash, so it's impossible to brick the device by writing an incompatible u-boot to the SPI flash (if you have physical access to the board). Yes, these boards are designed to be unbrickable. They can either boot from the SD card (there is a special sd card bootable image in sunxi-tools, which activates FEL mode), or have a dedicated FEL button. And main problem with Zero is its OTG port which serves as the main power input at the same time, so to reliably power the board for the FEL boot from a standard PC port you have to use microUSB Y-cable or power it through GPIO pins. The CPU is running at a really low clock speed in FEL mode (something like 384MHz?) and never uses more than one core. The current draw is much lower than 500mA. Idle FEL mode only shows ~80mA on my board. Unfortunately SPI NOR flash is not populated on my OpiZero board, but you can try to measure the current draw while flashing via sunxi-fel and report the results here. We are experimenting for now, and flashrom is convenient enough on the legacy kernel images since it works out of the box, doesn't require another PC, board or VM running Linux or compliing sunxi-tools for Windows (which may be a problem for an average user of this forum) Yeah, but you first need to boot the board from the SD card to use flashrom, so pick your poison As for the Windows version of sunxi-tools, you can try http://linux-sunxi.org/FEL/USBBoot#Using_sunxi-fel_on_Windows and provide some feedback.
zador.blood.stained Posted January 11, 2017 Posted January 11, 2017 Yeah, but you first need to boot the board from the SD card to use flashrom, so pick your poison As for the Windows version of sunxi-tools, you can try http://linux-sunxi.org/FEL/USBBoot#Using_sunxi-fel_on_Windows and provide some feedback. I compiled sunxi-fel before (with some adjustments to the Makefile, that was before Windows-specific branch was added to the main sunxi-tools repo) and I know that it works (for me), but we are talking about an average inexperienced user that read somewhere that SPI flash can be used to boot the system from USB flash, and here no prebuilt sunxi-fel binary with SPI programmer support will be the main problem. Also an alternative for the flashrom on the mainline (yes, still no verification about what we actually writing to the flash): &spi0 { status = "okay"; spi-flash@0 { #address-cells = <1>; #size-cells = <0>; compatible = "jedec,spi-nor"; reg = <0>; /* Chip select 0 */ spi-max-frequency = <3000000>; status = "okay"; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; partition@0 { label = "uboot"; reg = <0x0 0x100000>; }; partition@100000 { label = "env"; reg = <0x100000 0x100000>; }; partition@200000 { label = "data"; reg = <0x200000 0x600000>; }; }; }; }; Flashing: flashcp /usr/lib/linux-u-boot-dev-orangepizero_5.24_armhf/u-boot-sunxi-with-spl.bin /dev/mtd0 The CPU is running at a really low clock speed in FEL mode (something like 384MHz?) and never uses more than one core. The current draw is much lower than 500mA. Idle FEL mode only shows ~80mA on my board. Unfortunately SPI NOR flash is not populated on my OpiZero board, but you can try to measure the current draw while flashing via sunxi-fel and report the results here. OK, agree that 500mA is more than enough if nothing is plugged into the board and if it's not connected via a USB hub with other consumers plugged into the same hub (you can't underestimate the end user )
reamond Posted January 11, 2017 Author Posted January 11, 2017 Ok, I managed the flashing... I needed to add the chip model to the command (the size of the text is very small, its very had to read... but on my card its a "MX25L1606E"):So this worked without error:sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -w flash.img -c MX25L1605A/MX25L1606E/MX25L1608EI am not sure that boot works now from the USB... because the last part I did not managed to solve yet... I copy with dd the partition to USB... and than? You stated I would need to: "You will also need to adjust and recompile the boot script (on the USB FS), at least replacing "mmc" with "usb" in load commands" 1, So how can I do that... "step by step"... just baby steps for me )2, I also seen that some description includes an extra step... adding the drive to the "fstab"... is that needed? My USB, sda1 is "/dev/sda1: UUID="7dd0c931-6f7e-4fbd-83f6-544d0e1b2765" TYPE="ext4" PARTUUID="796122c3-01""So my guess that the fstab would include than something like this: "UUID="7dd0c931-6f7e-4fbd-83f6-544d0e1b2765 / ext4 defaults 0 1" 3, So other description also adds changes in "/boot/cmdline.txt" , where I would need to change "mmcblk0p2" to "sda1" But I dont have any such a file in my installation... at least I could not find it.... maybe I mixed it up with a Raspberry description. 4, Last but not least... there was a way to mount the SPI Flash to be able to access from the system... What should that be good for?
zador.blood.stained Posted January 12, 2017 Posted January 12, 2017 @reamond New images (the next stable release and nightlies) will work from USB out of the box (apart from partition resize which is not fixed yet) in the conditions that SD card is not inserted and only one USB storage device is onnected. As I said, in current state SPI boot requires understanding of the boot process. 1. Wait for the next nightly or release for your board or check the latest commits in the project repository. 2. Not needed 3. Not needed 4. SPI flash of this size can be used to store u-boot, its environment and maybe other boot related blobs. SPI flash of much larger size can be used to store small OS designed to work on mostly read-only storage (i.e. OpenWRT) on it.
reamond Posted January 12, 2017 Author Posted January 12, 2017 OK, so I tried with an upgrade to "ARMBIAN 5.24.170113 nightly Ubuntu 16.04.1 LTS 3.4.113-sun8i" and copy it to USB, As a second try, I also put ""Ubuntu Xenial server 4.9.0" image on the USB... Unfortionatly none of them come up with the SPI flashed earlier.
reamond Posted January 13, 2017 Author Posted January 13, 2017 I updated the SPI with the latest u-boot built... 5.24.170114 now it do some serious blinking on the ethernet port, which it didnt with the previous built. Unfortionatly its still not coming up with the USB... I dont have a working serial console yet (ordered one), so I cant see what its doing, but it definitely get stuck somewhere.
reamond Posted January 13, 2017 Author Posted January 13, 2017 Thanks! "ARMBIAN 5.24.170114 nightly Ubuntu 16.04.1 LTS 4.9.3-sun8i", the 4.9.3 is up with SPI boot from USB. Excellent! PS. Is there a new warning text on the "Nighty releases"... hope its not just for me ;O))
CursedPotato Posted January 15, 2017 Posted January 15, 2017 Does this mean we can use SPI based LCD's? or is that something else
Igor Posted January 15, 2017 Posted January 15, 2017 Does this mean we can use SPI based LCD's? or is that something else This topic is regarding booting from SPI flash (some boards has it) but SPI display should work too. Those drivers are included in both kernels.
loshia Posted January 30, 2017 Posted January 30, 2017 @reamond New images (the next stable release and nightlies) will work from USB out of the box (apart from partition resize which is not fixed yet) in the conditions that SD card is not inserted and only one USB storage device is onnected. Hello Zador, Can you confirm that if there is only one USB storage device connected, OPI zero will boot up (assuming everything else is ok - usb flash SPI chip contents and so on) even though if usb stick is NOT connected to OPI Zero USB OTG port. Excuse this silly question but i do not have Zero to test. In general i am preparing set of patches for NanaoPI NEO and M1 + SPI (laying) on socket + SPL boot from usb. Because my project requires the board to boot via USB port the one next to ethernet, i am wandering if some additional change must be made to make this to happen. Otherwise i am making my way with patches and building no problem with that. Thank you very much in advance PS: If there is more than one USB device connected let say One storage and three USB CDC devices (via socket with custom board) can USB bootable port (the one next to ethernet) to be somehow hardcoded inside by default? My guess is that the magic to choose USB port next to ethernet to be "bootable" is related with your comment ------------------------------------------------ You will also need to adjust and recompile the boot script (on the USB FS), at least replacing "mmc" with "usb" in load commands ------------------------------------------ For the moment i know i have to do these two as minimum: I have to add to sun8i-h3-nanopi-neo.dts: &spi0 { status = "okay"; spi-flash@0 { and so on I have to enable SPL in nanopi_neo_defconfig +CONFIG_SPL=y +# CONFIG_SPL_SPI_SUPPORT=y +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI_SUNXI=y Thank you very much in advance
martinayotte Posted January 30, 2017 Posted January 30, 2017 Yes, it will boot from USB, even if you have some USB CDC attached, because you have to specify the ' setenv rootdev "/dev/sda1" ' in the boot.cmd and recompile boot.scr
zador.blood.stained Posted January 30, 2017 Posted January 30, 2017 Can you confirm that if there is only one USB storage device connected, OPI zero will boot up (assuming everything else is ok - usb flash SPI chip contents and so on) even though if usb stick is NOT connected to OPI Zero USB OTG port. Excuse this silly question but i do not have Zero to test. I don't think OTG port is enabled as host in the u-boot by default, so it will work if USB flash is connected to any USB port other than OTG. PS: If there is more than one USB device connected let say One storage and three USB CDC devices (via socket with custom board) can USB bootable port (the one next to ethernet) to be somehow hardcoded inside by default? My guess is that the magic to choose USB port next to ethernet to be "bootable" is related with your comment Well, CDC is not a storage so it shouldn't count. This "only one USB storage" reguirement exists because there is no way to determine how many USB storage devices are connected (it can be implemented in theory, but it's not present by default), so the u-boot will try the USB storage device 0 (order of enumeration may be consistent) and will fail if it doesn't work (you can force u-boot to try several USB devices, but, again, it will require some patching) and since storing environment in SPI is not implemented yet you can't change the default number 0 to anything else without recompiling the u-boot. BTW, the latest boot script will work without any changes and the FS resizing procedure was updated too. 1
zador.blood.stained Posted January 30, 2017 Posted January 30, 2017 Yes, it will boot from USB, even if you have some USB CDC attached, because you have to specify the ' setenv rootdev "/dev/sda1" ' in the boot.cmd and recompile boot.scr Not needed since the default root device is specified by the FS UUID, and the UUID will still be valid if you flash the image to a USB storage instead of SD card.
loshia Posted January 30, 2017 Posted January 30, 2017 Super! I am not gonna waste your time anymore. When i got boards and test stuff i will get back with my results and patches hopefully Thank you very much
adrianoiot Posted July 14, 2017 Posted July 14, 2017 (edited) (Excuse my previous post was sent draft/incomplete) Hi, I'm trying to do same thing: "boot orange pi zero from SPI FLASH+USB pendrive without SD card". I think I followed all steps mention above but boot sequence is failing leading to a reset loop. This is all I have done: Soldered W25Q64 (8MB) SPI FLASH on Orange Pi Zero board. Flashed SD card with Armbian_5.30_Orangepizero_Ubuntu_xenial_default_3.4.113.7z, followed all procedure (update, upgrade, etc) Booted from SD without any issue. Plugged 8GB pendrive in USB near ethernet connector Installed armbian on pendrive (using armbian-config / install to sd nand ... menu) Reboot, boot OK from pendrive. dd if=/dev/zero count=4096 bs=1K | tr '\000' '\377' > spi.img dd if=/usr/lib/linux-u-boot-dev-orangepizero_5.24_armhf/u-boot-sunxi-with-spl.bin of=spi.img bs=1k conv=notrunc apt-get install flashrom flashrom -p linux_spi:dev=/dev/spidev0.0 -w spi.img flashrom error: Error: Image size (2097152 doesn't match the flash chip's size (8388608 B)! truncate spi.img -s 8388608 flashrom -p linux_spi:dev=/dev/spidev0.0 -w spi.img shutdown -h now Power off, removed sd card, power on Boot log (failing): U-Boot SPL 2017.05-armbian (Jun 15 2017 - 03:38:31) DRAM: 256 MiB Trying to boot from sunxi SPI U-Boot 2017.05-armbian (Jun 15 2017 - 03:38:31 +0200) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Zero DRAM: 256 MiB MMC: SUNXI SD/MMC: 0 MMC: no card present mmc_init: -123, time 2 *** Warning - MMC init failed, using default environment In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 MMC: no card present mmc_init: -123, time 2 MMC: no card present mmc_init: -123, time 1 ** Bad device mmc 0 ** MMC: no card present mmc_init: -123, time 2 MMC: no card present mmc_init: -123, time 2 ** Bad device mmc 0 ** MMC: no card present mmc_init: -123, time 2 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found USB device 0: Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC Type: Removable Hard Disk Capacity: 7599.0 MB = 7.4 GB (15562752 x 512) ... is now current device Scanning usb 0:1... BOOTP broadcast 1 data abort pc : [<4ff9a84c>] lr : [<000052c6>] reloc pc : [<4a03984c>] lr : [<fa0a42c6>] sp : 4bf3c940 ip : 00000000 fp : 4ffecff8 r10: 4ffecb4c r9 : 4bf40ee8 r8 : 0000000e r7 : 4ffeee84 r6 : 4ffeee8c r5 : 00000000 r4 : 4ffed04e r3 : 00060101 r2 : 00000008 r1 : 4ffecffe r0 : 0000000e Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... And keep rebooting and reseting over and over. What I am doing wrong? MANY THANKS!!! FOUND SOLUTION AFTER POSTED. NOW FIXED AND WORKING UHuuuuuu I finally CAN boot from SPI flash+USB pendrive with NO SD card inserted. Below are steps I did following all above and finally solved: Copied /boot directory from SD card to PENDRIVE with armbian image (which had an empty /boot directory...). Booted with both SD and PENDRIVE inserted edited /boot/boot.cmd, set: "setenv rootdev "/dev/sda1", save. compiled boot.cmd with: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr edited /etc/fstab, commented lines for: /media/mmcboot and /boot shutdown -h now power off removed SD power on, boot Voila!!! worked: booted from SPI FLASH + PENDRIVE with no SD inserted. Sorry about my posts going back and forward. Regards, Adrian Edited July 14, 2017 by adrianoiot FIXED AND NOW WORKING UHuuuuuu
solvess Posted September 15, 2017 Posted September 15, 2017 and can be /deb/devspi0.0 brought on board in this controller?
martinayotte Posted September 15, 2017 Posted September 15, 2017 You mean "/dev/spidev0.0" If you're running Legacy, enable it in FEX. If you're running Mainline, use "overlays=spi-spidev" in /boot/armbianEnv.txt. see https://docs.armbian.com/User-Guide_Allwinner_overlays/
Recommended Posts