2 2
reamond

OPI Zero boot with SPI

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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  :) )

Share this post


Link to post
Share on other sites

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/MX25L1608E

I 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?

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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))

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
(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:

  1. Soldered W25Q64 (8MB) SPI FLASH on Orange Pi Zero board.
  2. Flashed SD card with Armbian_5.30_Orangepizero_Ubuntu_xenial_default_3.4.113.7z, followed all procedure (update, upgrade, etc)
  3. Booted from SD without any issue.
  4. Plugged 8GB pendrive in USB near ethernet connector
  5. Installed armbian on pendrive (using armbian-config / install to sd nand ... menu)
  6. Reboot, boot OK from pendrive.
  7. dd if=/dev/zero count=4096 bs=1K | tr '\000' '\377' > spi.img
  8. 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
  9. apt-get install flashrom
  10. flashrom -p linux_spi:dev=/dev/spidev0.0 -w spi.img
    flashrom error:
    Error: Image size (2097152 B) doesn't match the flash chip's size (8388608 B)!
  11. truncate spi.img -s 8388608
  12. flashrom -p linux_spi:dev=/dev/spidev0.0 -w spi.img
  13. shutdown -h now
  14. Power off, removed sd card, power on
  15. 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:

  1. Copied /boot directory from SD card to PENDRIVE with armbian image (which had an empty /boot directory...).
  2. Booted with both SD and PENDRIVE inserted
  3. edited /boot/boot.cmd, set: "setenv rootdev "/dev/sda1", save.
  4. compiled boot.cmd with:  mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
  5. edited /etc/fstab, commented lines for: /media/mmcboot and /boot
  6. shutdown -h now
  7. power off
  8. removed SD
  9. power on, boot
  10. Voila!!! worked: booted from SPI FLASH + PENDRIVE with no SD inserted.

 

Sorry about my posts going back and forward.

Regards,

Adrian

 

Edited by adrianoiot
FIXED AND NOW WORKING UHuuuuuu

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
2 2