litex-hub / linux-on-litex-vexriscv

Linux on LiteX-VexRiscv
BSD 2-Clause "Simplified" License
574 stars 174 forks source link

spiflash not working correctly under linux (ecp5) #235

Open essele opened 3 years ago

essele commented 3 years ago

Hi,

I'm trying to build support for the muselabs icesugar_pro which is an ECP5 device, I can get everything running nicely on the sdcard and have just been experimenting with the spiflash. I have setup two partitions, one 2M for the FPGA bitstream and another 28M to experiment with jffs etc.

However whenever I read data (either from mtd0 or mtd1) I get the bitstream .. it actually looks like I get the same 128k of data repeated.

flash_erase on mtd1 appears to complete ok, but doesn't change the read behaviour, it's certainly not erased (or it could be, but I'm not reading valid data!)

The nor flash is a W25Q256 and is obviously working fine from a bitstream read perspective.

Here's my addition to the make.py file:

class iCESugar_Pro(Board):
    SPIFLASH_PAGE_SIZE    = 256
    SPIFLASH_SECTOR_SIZE  = 64*kB
    SPIFLASH_DUMMY_CYCLES = 8
    soc_kwargs = {"l2_size" : 2048} # Use Wishbone and L2 for memory accesses.
    def __init__(self):
        from litex_boards.targets import icesugar_pro
        Board.__init__(self, icesugar_pro.BaseSoC, soc_capabilities={
            # Communication
            "serial",
            # Storage
            "spiflash",
            "sdcard",
        }, bitstream_ext=".svf")

And the relevant section from the litex platform file:

    # SPIFlash
    ("spiflash", 0,
        Subsignal("cs_n", Pins("N8")),
        Subsignal("miso", Pins("T7")),
        Subsignal("mosi", Pins("T8")),
        Subsignal("wp", Pins("M7")),
        Subsignal("hold", Pins("N7")),
        IOStandard("LVCMOS33")
    ),
    ("spiflash4x", 0,
        Subsignal("cs_n", Pins("N8")),
        Subsignal("dq", Pins("T8", "T7", "M7", "N7")),
        IOStandard("LVCMOS33")
    ),

And the device tree bits to support partitions:

            litespiflash: spiflash@f0005800 {
                #address-cells = <1>;
                #size-cells    = <1>;
                compatible = "litex,spiflash";
                reg = <0xf0005800 0x100>;
                flash: flash@0 {
                    compatible = "jedec,spi-nor";
                    reg = <0x0 0x2000000>;
                    partitions {
                        compatible = "fixed-partitions";
                        #address-cells = <1>;
                        #size-cells = <1>;

                        partition@0 {
                            label = "fpga";
                            reg = <0x0 0x200000>;
                        };
                        partition@200000 {
                            label = "fs";
                            reg = <0x200000 0x1C00000>;
                        };
                    };
                };
            };

And relevant boot messages, which seem to be ok...

[   21.899792] litex-spiflash f0005800.spiflash: w25q256 (32768 Kbytes)
[   21.906354] 2 fixed-partitions partitions found on MTD device spi
[   21.911124] Creating 2 MTD partitions on "spi":
[   21.915617] 0x000000000000-0x000000200000 : "fpga"
[   22.067114] 0x000000200000-0x000001e00000 : "fs"

And mtdinfo output...

oot@buildroot:~# mtdinfo -a
Count of MTD devices:           2
Present MTD devices:            mtd0, mtd1
Sysfs interface supported:      yes

mtd0
Name:                           fpga
Type:                           nor
Eraseblock size:                4096 bytes, 4.0 KiB
Amount of eraseblocks:          512 (2097152 bytes, 2.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:0
Bad blocks are allowed:         false
Device is writable:             true

mtd1
Name:                           fs
Type:                           nor
Eraseblock size:                4096 bytes, 4.0 KiB
Amount of eraseblocks:          7168 (29360128 bytes, 28.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:2
Bad blocks are allowed:         false
Device is writable:             true

Any help greatly appreciated.

Lee.

enjoy-digital commented 3 years ago

Hi @essele,

we switched the LiteX-Boards to LiteSPI core snce then (https://github.com/litex-hub/litespi), would you mind testing with it and report if you still have troubles?

essele commented 3 years ago

Hi ... a few issues with the new approach (I think):

  1. The new modules seem to put a "spiflash_core" and "spiflash_phy" in the csr.json file rather than "spiflash" ... so tools/litex_json2dts_linux.py doesn't pick it up and therefore the dts/dtb files are incorrect.

  2. After manually fixing (or fixing json2dts) then it appears to build and boot, however the flash device isn't recognised at all...

[17.295830] litex-spiflash f0005800.spiflash: unrecognized JEDEC id bytes: 00 00 00 00 00 00 [17.299836] litex-spiflash f0005800.spiflash: SPI_NOR_SCAN FAILED [17.304125] litex-spiflash: probe of f0005800.spiflash failed with error -2

EDIT: Actually I may be being an idiot ... is there a different linux driver for this? I'm using the same kernel image so that could be the problem ... will investigate.

  1. (Not your issue) The icesugar_pro target does a self.add_spi_flash() which is duplicative to make.py.

Lee.

mithro commented 3 years ago

@mateusz-holenko

mateusz-holenko commented 3 years ago

It might be a driver problem. @kgugala could you take a look at that?

essele commented 3 years ago

I've just tried a new kernel, a full rebuild from buildroot as per the instructions and it's exactly the same.

Interestingly I'm also seeing fairly erratic behaviour as to whether the sdcard works ... I'm still trying to work out the pattern, I did think it was timing related, as it changes even with the exact same build parameters, but I'm not sure.

essele commented 3 years ago

Further info ... the problem with json2dts meant that I had my devicetree incorrect (the address has changed), however looking at csr.csv I can see that there are a different set of registers. The linux driver litex-spiflash.c still seems to expect the old style!

finchlt commented 1 year ago

I'm still seeing the same issue @essele describes on the current version of the linux driver. Any updates on how to proceed with spiflash in Linux.