ulx3s/Lobby

emard

@emard

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

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:

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?

You could try taking out the sd card and putting it back in when in u-boot and then doing mmc rescan and mmc part, and it it lists partitions, do "boot".

Thomas Hornschuh

@ThomasHornschuh

My problem is solved, the first SD card was "dead". Bit strange anyway, because I was sure that it worked before.

Paul Ruiz

@pnru_gitlab

Ok, I've done a bit more reading and also scanned the ISSI datasheet. You guys probably already thought of all the below, but just to make sure. My current understanding of the "all cases covered" reset sequence is as follows:

set CLK low and CS high
wait for 15ms to give time to any command (other than erase types) to complete
send 0xAB, 0xFF, 0xFF, 0xFF, read ID byte in quad mode
wait 5us
send 0x66, 0x99 in quad mode
wait 35 us
make sure that HOLD & WP are high.
send 0xAB, 0xFF, 0xFF, 0xFF, read ID byte in regular SPI mode
wait 5us
send 0x66, 0x99 in regular SPI mode
wait 35 us

Larry Wall once observed that "given enough eye balls, all bugs are shallow". It seems to me we don't have enough eye balls yet :^)

Dolu1990

@Dolu1990

thanks ^^

Hmmm, yet i don't have the quad mode in the hardware

Thomas Hornschuh

@ThomasHornschuh

This time I wrote the image with SD Imager from Windows, unfortunately there is no way for VMWare to pass a raw SD card to a Linux VM. Currently I have no computer with an SD card reader booting Linux natively

But anyway, I was sucessfull. I will take a look into the newer SaxonSoC in the next days. I was observing this gitter channel briefly in the past few months waiting or my board to arrive. But today my goal was to bring the board up running, mission acomplished !

Lawrie Griffiths

@lawrie

I use a USB sd card reader with the VirtualBox VM that I use.

Paul Ruiz

@pnru_gitlab

@ThomasHornschuh What OS is the machine with the SDCard reader natively using?

Thomas Hornschuh

@ThomasHornschuh

Thank you to everyone helping me today. I have never seen an FPGA board with such an active community before, I'm looking forward for doing more with ulx3s !

Where communities thrive

People

Repo info

Activity