Any Support for booting from Spi Flash?

I note your NOR write speed is much higher than the best I’ve seen which is 100kB/s. Not sure what to make of that.

Please see my earlier comment about reducing the SPI bus speed. Also the connection quality needs to be very good… a breadboard won’t cut it in this case.

yeh i cant really build complete images only fip and boot.spinor succeeds and being built the rootfs fails

1 Like

I guess, you can borrow those files from my package and only change the U-Boot, if you can build it.

Otherwise, if you know what should be changed in the code to reduce the SPI bus speed, I’ll be more than happy to try and rebuild it with such changes.

I got it to boot with Spi Flash by not using any of the milk vs tools. I wrote a tool to flash spi chips and it came in handy. Though it cant load the Linux image for some reason. I flashed each file at the correct address

0x0 - fip.bin
0xA0000 - boot.spinor
0x4B0000 - rootfs.spinor

C.SCS/0/0.WD.URPL.USBI.BS/NOR.PS.PE.BS.BE.J.
FSBL Jb28g9:gad359c401:2024-07-30T08:46:03+03:00
st_on_reason=4090003
st_off_reason=0
P2S/0x1000/0x3bc0da00.
P2E.
DPS/0xda00/0x2000.
DPE.
DDR init.
ddr_param[0]=0x78075562.
pkg_type=3
D3_1_4
DDR2-512M-QFN68
Data rate=1333.
DDR BIST PASS
PLLS.
PLLE.
C2S/0xfa00/0x83f40000/0x3600.
RSC.
CR2TE:. 
[
1M.S2/102x210320]0P0r/e0 xs8y0s0t0e0m0 0i0n/i0tx 1dbo0n0e0
RT: [1.218521]CVIRTOS Build Date:Jul 30 2024  (Time :08:46:03) 
RT: [1.224524]Post system init done
RT: [1.227840]create cvi task
RT: [1.230667][cvi_spinlock_init] succeess
RT: [1.234560]prvCmdQuRunTask run
ME.
L2/0x2e000.
L2/0x414d3342/0xcafede84/0x80200000/0x3be00/0x3be00
COMP/1.
DCP/0x80200020/0x1000000/0x81500020/0x3be00/1.
DCP/0x7d32c/0.
Loader_2nd loaded.
Use internal 32k
Jump to monitor at 0x80000000.
OPENSBI: next_addr=0x80200020 arg1=0x80080000
OpenSBI v0.9
  ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : Cvitek. CV180X ASIC. C906.
Platform Features         : mfdeleg
Platform HART Count       : 1
Platform IPI Device       : clint
Platform Timer Device     : clint
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform SysReset Device  : ---
Firmware Base             : 0x80000000
Firmware Size             : 132 KB
Runtime SBI Version       : 0.3

Domain0 Name              : root
Domain0 Boot HART         : 0
Domain0 HARTs             : 0*
Domain0 Region00          : 0x0000000074000000-0x000000007400ffff (I)
Domain0 Region01          : 0x0000000080000000-0x000000008003ffff ()
Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x0000000080200020
Domain0 Next Arg1         : 0x0000000080080000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 0
Boot HART Domain          : root
Boot HART ISA             : rv64imafdcvsux
Boot HART Features        : scounteren,mcounteren,time
Boot HART PMP Count       : 16
Boot HART PMP Granularity : 4096
Boot HART PMP Address Bits: 38
Boot HART MHPM Count      : 8
Boot HART MHPM Count      : 8
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109

U-Boot 2021.10 (Jul 30 2024 - 08:45:13 +0300)cvitek_cv180x

DRAM:  63.3 MiB
gd->relocaddr=0x823f3000. offset=0x21f3000
MMC:   cv-sd@4310000: 0
Loading Environment from SPIFlash... spinor id = C2 20 19
SF: Detected MX25L25645G with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   
Warning: ethernet@4070000 (eth0) using random MAC address - 4e:40:7d:cc:60:b5
eth0: ethernet@4070000
Hit any key to stop autoboot:  1  0 
spinor id = C2 20 19
SF: Detected MX25L25645G with page size 256 Bytes, erase size 4 KiB, total 32 MiB
device 0 offset 0xa0000, size 0x400000
SF: 4194304 bytes @ 0xa0000 Read: OK
sf read speed 31.775 MB/s
Wrong Image Format for bootm command
ERROR: can't get kernel image!
## Error: "nandboot" not defined
## Error: "emmcboot" not defined
cv180x_c906# 
1 Like

Now I’m curious to reproduce that. I don’t currently have any SPI flash chips of a capacity bigger than 16 mebibytes, but in some days I think I will.

I can only get the fip.bin which has the bootloader and uboot to work on spi flash. The linux image fails to load. So i dont know what the problem it has. The milk v i have doesn’t flash the chip correctly.

I connected the pins like @ewp stated but no success. For it to even write to flash the wp & reset/hold pins had to be connected to 3.3v( which is normal for Single or Dual Spi mode) in Quad mode the chip doesnt get programmed or erased.

If it gets programmed by milk v (tying WP and Hold to 3.3v ,which is not using wp and hold pins on milk v) the data is not right which is funny considering i correctly programmed the chip from a usb to serial adapter which is a mess of wires… and when i connected it to milk v , it booted to uboot immediately lol…

So unless someone has a known working image and i mean an image that has successfully boot completely off spi flash from uboot to linux then I might try it.

Assuming Milk Vs spi driver isnt half baked and just ignores smaller size chips then you can fit fip.bin on it. If you have a chip programmer then just flash it at 0x0.

1 Like

Since you are not wiring for quad SPI you should disable this mode for your IC in U-Boot, then these reads and writes in U-Boot will work. I’m sure I could dump the mtd blocks from a working 32 MB SPI NOR flash if you get really stuck, but you should ideally look at your Linux build environment setup.

1 Like

The official flash support list shows support for SPI NOR as small as 8 MB (Q64). You can fit U-Boot and Linux into this and maybe even a small initramfs.

As long as the MCU boots you can add further flash chips into the U-Boot list. I did this to get some cheap 8 MB SPI NOR DIP chips working which are not officially supported.

You could probably strip buildroot packages and change the partition tables to build for 16 MB (Q128).

1 Like

The milk v is not writing to the flash correctly. This problem only occurs on the milk v. I programmed the chip in Spi mode 0 from my custom software. And it boots when connected to the milkv. So it has nothing to do with spi modes or pins milk v used . even if the chip is in Single, Dual or Quad mode it will still boot or flash.

And Again I did wire it like you told me which is QSPI mode because WP and Hold pins are the SIO2 and SIO3 data pins in QSPI mode. and it still doesnt work. IT JUST READS. Flashing fails in this mode (incorrect data or data overrite possible ). So the problem can possible be the SPi driver not handling chips over 16 MB well because chips below 16 MB use 24 bit page program command while over 16 MB uses 32 bit Page program. So it could be overritting the data if its using 24 bit page program. Another issue could be incorrect clk or unstable base clock but i dont have oscilloscope to check.

Also i cannot build complete images with WSL on Windows. I followed the wsl instructions but still cant get past building the rootfs. Thats why i am asking for an Image that has successfully booted correct as far as into linux. Not just the uboot stage

1 Like

Here you go, fully working compressed 32MB SPI NOR flash image created and uploaded. Let me know if you need it split.

1 Like

You said this is a working image then probably something is missing . I flash the whole image and it still cant load kernel( Unless its supposed to do this idk)
Tbh im really starting to think i have a bad board now

Loading Environment from SPIFlash... spinor id = C2 20 19
SF: Detected MX25L25645G with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   
Warning: ethernet@4070000 (eth0) using random MAC address - da:0e:2a:89:b2:6d
eth0: ethernet@4070000
Hit any key to stop autoboot:  1  0 
spinor id = C2 20 19
SF: Detected MX25L25645G with page size 256 Bytes, erase size 4 KiB, total 32 MiB
device 0 offset 0xa0000, size 0x400000
SF: 4194304 bytes @ 0xa0000 Read: OK
sf read speed 31.536 MB/s
Wrong Image Format for bootm command
ERROR: can't get kernel image!
## Error: "nandboot" not defined
## Error: "emmcboot" not defined
ethernet@4070000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@4070000
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/C0A80003
1 Like

Yes, this message about PXE boot (network boot off of another host on LAN) looks suspicious.

Hi @KeiKai

*** Warning - bad CRC, using default environment

This line is interesting and shows ROM can read flash but U-Boot cannot. I see this:

Loading Environment from SPIFlash... spinor id = EF 40 19
SF: Detected W25Q256JV-IQ with page size 256 Bytes, erase size 4 KiB, total 32 MiB
OK

@hannahKobain the PXE network boot is not suspicious, it’s because this is my branch which runs PXE boot if all else fails.

cv180x_c906# printenv bootcmd 
bootcmd=cvi_update || run norboot || run nandboot || run emmcboot || run pxeboot

Symptoms indicate an issue with the quad lines. This could be anywhere from the board to the flash chip. What do you get when you run this?

cv180x_c906# sf probe
spinor id = EF 40 19
SF: Detected W25Q256JV-IQ with page size 256 Bytes, erase size 4 KiB, total 32 MiB
cv180x_c906# sf read 0x81400000 0 256
device 0 offset 0x0, size 0x256
SF: 598 bytes @ 0x0 Read: OK
sf read speed 0.119 MB/s
cv180x_c906# md.l 0x81400000 64
81400000: 4c425643 000a3130 00000000 cafe0a7e  CVBL01......~...
81400010: 00000000 00000000 00000000 00000000  ................
81400020: 00000000 00000000 00000000 00000000  ................
81400030: 00000000 00000000 00000000 00000000  ................
81400040: 00000000 00000000 00000000 00000000  ................
81400050: 00000000 00000000 00000000 00000000  ................
81400060: 00000000 00000000 00000000 00000000  ................
81400070: 00000000 00000000 00000000 00000000  ................
81400080: 00000000 00000000 00000000 00000000  ................
81400090: ffffffff ffffffff ffffffff ffffffff  ................
814000a0: ffffffff ffffffff ffffffff ffffffff  ................
814000b0: ffffffff 00000000 00000000 000002f8  ................
814000c0: cafe0000 00000000 05200200 00000000  .......... .....
814000d0: 00000000 cafe5256 0000ba00 00000000  ....VR..........
814000e0: 0000ca00 00000000 0e00000c a0000001  ................
814000f0: 0e00000c a0000002 ffffffa0 ffffffff  ................
81400100: 00000000 00000000 00000000 00000000  ................
81400110: 00000000 00000000 00000000 00000000  ................
81400120: 00000000 00000000  00000000 00000000  ................
81400150: 00000000 00000000 00000000 00000000  ................
81400160: 00000000 00000000 00000000 00000000  ................
81400170: 00000000 00000000 00000000 00000000  ................
81400180: 00000000 00000000 00000000 00000000  ................

Can you build a new FSBL with disabled quad SPI and retry? Apply this patch and rebuild the fip.bin and put on TF card. Interrupt U-Boot before it rewrites your flash and run norboot direct from the TF card.

diff --git a/u-boot-2021.10/drivers/mtd/spi/spi-nor-core.c b/u-boot-2021.10/drivers/mtd/spi/spi-nor-core.c
index 5c8726bee..0a59cc77c 100644
--- a/u-boot-2021.10/drivers/mtd/spi/spi-nor-core.c
+++ b/u-boot-2021.10/drivers/mtd/spi/spi-nor-core.c
@@ -2353,11 +2353,11 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
                params->quad_enable = spansion_no_read_cr_quad_enable;
                break;
 #endif
-#if defined(CONFIG_SPI_FLASH_MACRONIX) || defined(CONFIG_SPI_FLASH_ISSI)
-       case BFPT_DWORD15_QER_SR1_BIT6:
-               params->quad_enable = quad_enable_SR_bit6;
-               break;
-#endif
+//#if defined(CONFIG_SPI_FLASH_MACRONIX) || defined(CONFIG_SPI_FLASH_ISSI)
+//     case BFPT_DWORD15_QER_SR1_BIT6:
+//             params->quad_enable = quad_enable_SR_bit6;
+//             break;
+//#endif
 #if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
        case BFPT_DWORD15_QER_SR2_BIT1:
                params->quad_enable = spansion_read_cr_quad_enable;
@@ -2744,7 +2744,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
        if (params->hwcaps.mask & (SNOR_HWCAPS_READ_QUAD |
                                   SNOR_HWCAPS_PP_QUAD)) {
                switch (JEDEC_MFR(info)) {
-               case SNOR_MFR_MACRONIX:
+//             case SNOR_MFR_MACRONIX:
                case SNOR_MFR_ISSI:
                        params->quad_enable = quad_enable_SR_bit6;
                        break;
diff --git a/u-boot-2021.10/drivers/mtd/spi/spi-nor-ids.c b/u-boot-2021.10/drivers/mtd/spi/spi-nor-ids.c
index e194e41ee..b10b1e19a 100644
--- a/u-boot-2021.10/drivers/mtd/spi/spi-nor-ids.c
+++ b/u-boot-2021.10/drivers/mtd/spi/spi-nor-ids.c
@@ -70,7 +70,7 @@ const struct flash_info spi_nor_ids[] = {
                SPI_NOR_QUAD_READ | SECT_4K) },
        /* Juyang 32M Nor Flash(JY25VQ256A) uses the same wafers as MXIC */
        { INFO("MX25L25645G", 0xc22019, 0x0, 64 * 1024, 512,
-               SPI_NOR_QUAD_READ | SECT_4K | SPI_NOR_4B_OPCODES) },
+               0x00 | SECT_4K | SPI_NOR_4B_OPCODES) },
        { INFO("MX25L12835F", 0xc22018, 0x0, 64 * 1024, 256,
                SPI_NOR_QUAD_READ | SECT_4K) },
        { INFO("EN25QH128A", 0x1c7018, 0x0, 64 * 1024, 256,

I cannot test this myself since I do not own this IC.

1 Like

With and without out QSPI lines connected same result

cv180x_c906# sf probe
spinor id = C2 20 19
SF: Detected MX25L25645G with page size 256 Bytes, erase size 4 KiB, total 32 MiB
cv180x_c906# sf read 0x81400000 0 256
device 0 offset 0x0, size 0x256
SF: 598 bytes @ 0x0 Read: OK
sf read speed 0.119 MB/s
cv180x_c906# md.l 0x81400000 64
81400000: bbbbbb9b bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400010: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400020: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400030: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400040: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400050: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400060: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400070: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400080: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400090: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
814000a0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
814000b0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
814000c0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
814000d0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
814000e0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
814000f0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400100: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400110: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400120: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400130: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400140: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400150: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400160: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400170: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
81400180: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb  ................
1 Like

So does your board boot up right off of a TF card? Just curious.
For me, a TF card is a much better choice since you mentioned you want to use it with Arduino, and I guess you will be overwriting the file with the second-core firmware quite often, therefore the more address space you have for the rootfs partition, the better. Of course, for the final project an SPI flash chip may suit better.

So, do normal images work fine?

I can explain why I’m asking:

  1. This is important, so that we confirm your board can boot.
  2. With the board booted off of a TF card, we can try and access the SPI NOR flash chip you have via SPI interface (SPI0 or SPI1 — doesn’t matter).

Your output shows U-Boot cannot read what the ROM could. How does this look with the updated U-Boot I provided the patch for?

1 Like

Yes it boots off memory card properly.

1 Like

i was trying to build the fip.bin when I lost power for a few hours lol. So will try again

1 Like

Same wrong looking data.

1 Like

Did U-Boot show a new build timestamp? That does not make much sense, but I do not have that flash chip to be sure. Please could you try with Winbond W25Q256JVEQ.

1 Like