Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    David Shah
    @daveshah1
    That would only be if you request that
    ie with the ecppack --spimode argument
    Although actually I don't think that uses full quad mode
    Just the quad read command
    emard
    @emard
    @Dolu1990 yes quad read mode could be possible, we can fix this by flashing directly your or another bitstream which will set it 1-bit mode
    @Dolu1990 I have made experiment that after 85F boots, I read SPI flash in 1-bit mode from esp32 and that works normally. Flash can be also written in 1-bit mode. Actually to all other operations flash just appears as normal.
    Dolu1990
    @Dolu1990
    Hoo right, thanks
    emard
    @emard
    board should still be online
    I think you can upload "passthru" bitstream from "ecp5_prog" directory and the connect tp ttyUSB0 115200, you should see micropython prompt. Then import ecp5; ecp5.flashrd(addr, length) or ecp5.flash("bitstream.bit") flash should work
    Dolu1990
    @Dolu1990
    No no, it's fine, David is right, the FPGA would only use regular quad command, it will not change the mod
    emard
    @emard
    I will try micropython now 
    >>> ecp5.flashrd(0,32)
bytearray(b'\xff\x00Lattice Semiconductor Corporat')
    see flash is alive
    you can try the same on board remotely
    emard
    @emard
    wrong addr... hex
    Dolu1990
    @Dolu1990
    So, 0x340000 is opensbi
    while 0x380000 is uboot
    emard
    @emard
    >>> ecp5.flashrd(0x340000,32)
bytearray(b'3\x04\x05\x00\xb3\x84\x05\x003\t\x06\x00\xef\x00@v3\x08\x05\x003\x05\x04\x00\xb3\x85\x04\x003\x06\t\x00')
>>> ecp5.flashrd(0x380000,32)
bytearray(b'\x13\x02\x05\x00\x93\x84\x05\x00\x97\xc2\x06\x00\x83\xa2\x82\xd9s\x90R\x10s\x10@\x10\x93\x02@\x00cRR"')
    Dolu1990
    @Dolu1990
    Look right
    except opensbi one
    is that big or small endian ?
    emard
    @emard
    Can we reflash them with correct content using fujprog and then try to read again
    I can download from lawrie site and flash
    Dolu1990
    @Dolu1990
    But anyway, i was reading only FF and wrong flash id
    0xFF flash id
    emard
    @emard
    Yes to your core it looks like hardware protocol to the chip is wrong, or 0xAB command didn't succeed. How about chip was clocked before and had some incomplete byte pending, maybe 0xAB several times?
    Dolu1990
    @Dolu1990
    Yes, maybe some glitch / inclomplet commands which locked it
    emard
    @emard
    That could easily be. Maybe I can find some miniature flash chip clip and some suitable wires for scoping it if you think that may reveal situation
    Lawrie Griffiths
    @lawrie
    @emard @Dolu1990 I did not quite follow this discussion. Have we found what the problem with the flash is or was?
    Dolu1990
    @Dolu1990
    no, not yet
    currently, scoping would be usefull i think
    Also, i can step by step the spi access while scoping, to ease the capture
    emard
    @emard
    I have upgraded firmware of a hardware scope. it should have a junky logic analzyer. Inside is a large zynq so once I should reflash this box to something more useful like saxonsoc :)
    Now I'm looking for suitable pins to connect to the probes. Still I'm thinking should have I used hdl4fpga scopeio instead of this big box
    Thomas Hornschuh
    @ThomasHornschuh
    I'm now at the point that SaxonSoC starts into u-boot, but it seems that it can't access the sd card. I used the binary release from here https://github.com/dok3r/ulx3s-saxonsoc/releases , installed SD image over ftp with put saxonsoc-sdimage.raw sd@0, took a long time
    It says "wrong image format for bootm command. All uboot mmc commands did return nothing
    Paul Ruiz
    @pnru_gitlab

    @Dolu1990 @emard As I understand the conversation, the current hypothesis is that the flash rom gets in a confused state during FPGA load.

    That brought back a memory of working on an i2c driver (h/w and s/w) a few weeks backs for the Cortex. To get it working, one of the things was to always reset the bus/devices. For i2c this means clocking the bus until all devices release the data line and then issuing a start and a stop condition, as a stop condition terminates any pending command.

    I could imagine that the flash SPI bus may need something similar, like clocking it for n pulses followed by a "soft reset" command to the device (if such a command exists).

    emard
    @emard
    Hypothesis is either protocol timing/edges are incorrect or flash is in unknown state. I was suggesting multiple 0xAB commands, if first doesnt succeed maybe 2nd or 3rd would
    Paul Ruiz
    @pnru_gitlab
    I found this quote online: There are many Dual- and Quad read modes that are not sticky, they only are valid until CS goes high. Using these modes will not affect SPI booting. Only the QPI mode remains active after a CS high. This can be reset to SPI on most Flash chips with the command $FF sent in QPI mode (ISSI says $F5).
    It continues: Alternatively you can send the Reset sequence $66,$99 in QPI mode as first boot activity. This will not be valid commands in SPI mode, because CS goes high after 2 bits:
    img

    So maybe try:

    • set CS high
    • send 0xff to give the flash some clocks
    • set CS low
    • send the 0xff command
    • send the 0xf5 command

    ???

    Dolu1990
    @Dolu1990

    @pnru_gitlab Adding : 

        spi_write(SPI, 0xFF);
    bsp_uDelay(200);

    spiFlash_select(SPI,SPI_CS);
    spi_write(SPI, 0xFF);
    spi_write(SPI, 0xF5);
    spiFlash_diselect(SPI,SPI_CS);
    bsp_uDelay(200);

    Do not change the behaviour, just tested :(

    Paul Ruiz
    @pnru_gitlab

    Now I came across this, apparently JEDEC standard JESD252 specifies a method to reset an SPI flash chip. If I understand the figure correctly, CLK is held low (in mode 0) and CS is used to clock the chip. The data line must carry 0-1-0-1 for a reset to happen:

    img

    Dolu1990
    @Dolu1990
    lol
    Paul Ruiz
    @pnru_gitlab
    Sorry - I am behaving like a cat dragging random stuff into the house.
    Dolu1990
    @Dolu1990
    magnificent
    no no, that's nice
    Paul Ruiz
    @pnru_gitlab
    It seems that the JESD252 document is not freely available. It also seems to be quite new - so this may be something that is coming, not something that has been around for a while. It does indicate that other ways to achieve a reset were perhaps not so easy - as we are experiencing.
    Dolu1990
    @Dolu1990
    Just tried, it do not seem to have any impact
    But now we will mesure the pins, to be sure we do what we think we do ^
    Lawrie Griffiths
    @lawrie
    @ThomasHornschuh That version of SaxonSoc is a bit out of date. We are currently running the newer Smp version. @kost has not yet built an Smp version, but there are versions in my repository - https://github.com/lawrie/saxonsoc-ulx3s-bin/tree/master/Smp. Currently, you have to create the sd card manually for this version and it now has 2 partitions, the first being FAT32.
    However, the version you are using should work. Can you look at the sd card from your Linux machine to see if it contains a sensible ext2 partition?