Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    Most of the retro-computing stuff loads roms via the ESP32 using an OSD (on-screen display) which overlays the HDMI output and lets you choose files from an SD card or the ESP32 flash memory using the buttons (or sometimes a game controller). You need to upload and import osd.py for that. The versions of osd.py differ a bit.
    You start te OSD by pressing all 4 buttons at once.
    You sometimes need an extra .py file as well as osd.py.
    @goran-mahovlic Even if Wifi is on, you really need to change main.py to connect to your router and get an IP address.
    Thomas Hornschuh
    @ThomasHornschuh
    @goran-mahovlic Just looked at the updated quick-start. The frist chapter states to run the "test scripts". I tried to understand what they do, but do be honest this is quite confusing. I hope you don't feel anoyed by my remarks, but I know from Feedback I get from users of my own FPGA projects, that many people trying their first steps with an FPGA board are much less skilled than I, also with basic Linux things. But if you want to avoid that buyers of this board get discouraged. So just maybe just remove the "know-your-programmer" chapter and state that the quick-start is for the production boards sold over Crowd-Supply and inteded for a clean start with newest tools.
    Goran Mahovlic
    @goran-mahovlic
    I moved this chapter to the end of the page
    No, thank you for remarks, as we all know where to start from, and we really need user feedback
    Goran Mahovlic
    @goran-mahovlic
    But you are right - I removed "test script and issue" from Quickstart and left use new fujprog
    Thomas Hornschuh
    @ThomasHornschuh

    Ignoring all my detours I did, the sucessfull way for me was

    At the end it this is very simple and straight forward, and will take maybe 30 Minutes if you do it right at the first try

    Dolu1990
    @Dolu1990
    Is it possible that the SPI IS25LP128F flash is setup in quad mode by the ECP5 ?
    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 :(