mhanuel26 commented 6 years ago

Hello,

I understand that Arty A7 is supported, I want to confirm if Arty S7 need something extra to work. I follow the build instructions and when loading the gateware on Arty S7 I am getting the following error.

(LX P=arty T=base F=micropython) mhanuel@04c4dbb5f53a:~/Devel/Arty/src/litex-buildenv$ make gateware-load openocd -f board/digilent_arty.cfg -c "init; pld load 0 build/arty_base_lm32//gateware/top.bit; exit" Open On-Chip Debugger 0.10.0+dev-00272-gedb679628-dirty (2018-01-19-15:08) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html none separate adapter speed: 10000 kHz Info : auto-selecting first available session transport "jtag". To override use 'transport select '. jtagspi_program Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling" Info : clock speed 10000 kHz Info : JTAG tap: xc7.tap tap/device found: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0) Warn : JTAG tap: xc7.tap UNEXPECTED: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0) Error: JTAG tap: xc7.tap expected 1 of 27: 0x0362e093 (mfg: 0x049 (Xilinx), part: 0x362e, ver: 0x0) Error: JTAG tap: xc7.tap expected 2 of 27: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0) Error: JTAG tap: xc7.tap expected 3 of 27: 0x0362c093 (mfg: 0x049 (Xilinx), part: 0x362c, ver: 0x0) Error: JTAG tap: xc7.tap expected 4 of 27: 0x03632093 (mfg: 0x049 (Xilinx), part: 0x3632, ver: 0x0) Error: JTAG tap: xc7.tap expected 5 of 27: 0x03631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x0) Error: JTAG tap: xc7.tap expected 6 of 27: 0x03636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x0) Error: JTAG tap: xc7.tap expected 7 of 27: 0x03647093 (mfg: 0x049 (Xilinx), part: 0x3647, ver: 0x0) Error: JTAG tap: xc7.tap expected 8 of 27: 0x0364c093 (mfg: 0x049 (Xilinx), part: 0x364c, ver: 0x0) Error: JTAG tap: xc7.tap expected 9 of 27: 0x03651093 (mfg: 0x049 (Xilinx), part: 0x3651, ver: 0x0) Error: JTAG tap: xc7.tap expected 10 of 2: 0x03747093 (mfg: 0x049 (Xilinx), part: 0x3747, ver: 0x0) Error: JTAG tap: xc7.tap expected 11 of 2: 0x03656093 (mfg: 0x049 (Xilinx), part: 0x3656, ver: 0x0) Error: JTAG tap: xc7.tap expected 12 of 2: 0x03752093 (mfg: 0x049 (Xilinx), part: 0x3752, ver: 0x0) Error: JTAG tap: xc7.tap expected 13 of 2: 0x03751093 (mfg: 0x049 (Xilinx), part: 0x3751, ver: 0x0) Error: JTAG tap: xc7.tap expected 14 of 2: 0x03671093 (mfg: 0x049 (Xilinx), part: 0x3671, ver: 0x0) Error: JTAG tap: xc7.tap expected 15 of 2: 0x036b3093 (mfg: 0x049 (Xilinx), part: 0x36b3, ver: 0x0) Error: JTAG tap: xc7.tap expected 16 of 2: 0x036b7093 (mfg: 0x049 (Xilinx), part: 0x36b7, ver: 0x0) Error: JTAG tap: xc7.tap expected 17 of 2: 0x036bb093 (mfg: 0x049 (Xilinx), part: 0x36bb, ver: 0x0) Error: JTAG tap: xc7.tap expected 18 of 2: 0x036bf093 (mfg: 0x049 (Xilinx), part: 0x36bf, ver: 0x0) Error: JTAG tap: xc7.tap expected 19 of 2: 0x03667093 (mfg: 0x049 (Xilinx), part: 0x3667, ver: 0x0) Error: JTAG tap: xc7.tap expected 20 of 2: 0x03682093 (mfg: 0x049 (Xilinx), part: 0x3682, ver: 0x0) Error: JTAG tap: xc7.tap expected 21 of 2: 0x03687093 (mfg: 0x049 (Xilinx), part: 0x3687, ver: 0x0) Error: JTAG tap: xc7.tap expected 22 of 2: 0x03692093 (mfg: 0x049 (Xilinx), part: 0x3692, ver: 0x0) Error: JTAG tap: xc7.tap expected 23 of 2: 0x03691093 (mfg: 0x049 (Xilinx), part: 0x3691, ver: 0x0) Error: JTAG tap: xc7.tap expected 24 of 2: 0x03696093 (mfg: 0x049 (Xilinx), part: 0x3696, ver: 0x0) Error: JTAG tap: xc7.tap expected 25 of 2: 0x036d5093 (mfg: 0x049 (Xilinx), part: 0x36d5, ver: 0x0) Error: JTAG tap: xc7.tap expected 26 of 2: 0x036d9093 (mfg: 0x049 (Xilinx), part: 0x36d9, ver: 0x0) Error: JTAG tap: xc7.tap expected 27 of 2: 0x036db093 (mfg: 0x049 (Xilinx), part: 0x36db, ver: 0x0) Error: Trying to use configured scan chain anyway... Warn : Bypassing JTAG setup events due to errors Info : Listening on port 3333 for gdb connections loaded file build/arty_base_lm32//gateware/top.bit to pld device 0 in 1s 836420us

I have been digging the code and found that there is a file ./platforms/arty.py which contains the signals and xilinx p/n for Arty A7.

Should be this the starting point to make the port to S7?

I will appreciate your comments,

mithro commented 6 years ago

It looks like something is going wrong with JTAG programming

mhanuel26 commented 6 years ago

Yes, you are right, I haven't use before openocd with Xilinx on my linux box. So I am not sure if it fails because of JTAG hardware issue or is something more related to bad configuration of the top.bit, which actually build correctly, but since my board is S7 and not A7...

Do you know how can I program it using Vivado?

mithro commented 6 years ago

You can't program a Arty A7 bitstream onto a Arty S7. They are not the same device.

mithro commented 6 years ago

@cr1901 is working on adding support for the Arty S7 to the LiteX-buildenv which Fupy uses. Once that support is working, then Fupy should just work too.

mhanuel26 commented 6 years ago

Yes you are certainly right,

Could you please let me know which files should I look to change for make this project available for S7?

I suspect one is ./platforms/arty.py, but if you can give me some details so I can go after them quickly I will appreciate you.

mhanuel26 commented 6 years ago

@cr1901 @mithro Is there any preview of S7 platform ? Or a time frame, anything I can contribute, at least doing tests? If possible a brief overview of the required changes to support S7?

mithro commented 6 years ago

@cr1901 can give you more information.

The primary thing which needs to work is the DDR memory on the board. Once that works, everything else should be pretty easy.

mhanuel26 commented 6 years ago

@mithro As far as I understand both boards have same DDR3 memory P/N MT41K128M16JT-125 . Perhaps the problem I am seeing is more related to Quad-SPI memory since it fails in the very first stage of openocd load.

Actually Arty-A7 has Micron part number N25Q128A13ESF40, and Arty S7 has Spansion part number S25FL128S.

I found that Quad-SPI is defined in arty.py file as below

class Platform(XilinxPlatform):
    name = "arty"
    default_clk_name = "clk100"
    default_clk_period = 10.0

    # From https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
    # 17536096 bits == 2192012 == 0x21728c -- Therefore 0x220000
    gateware_size = 0x220000

    # Micron N25Q128A13ESF40 (ID 0x0018ba20)
    # FIXME: Create a "spi flash module" object in the same way we have SDRAM
    # module objects.
    spiflash_model = "n25q128a13"
    spiflash_read_dummy_bits = 10
    spiflash_clock_div = 4
    spiflash_total_size = int((128/8)*1024*1024) # 128Mbit
    spiflash_page_size = 256
    spiflash_sector_size = 0x10000

    def __init__(self, toolchain="vivado", programmer="openocd"):
        XilinxPlatform.__init__(self, "xc7a35t-csg324-1", _io,
                                toolchain=toolchain)
        self.toolchain.bitstream_commands = \
            ["set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design]"]
        self.toolchain.additional_commands = \
            ["write_cfgmem -force -format bin -interface spix4 -size 16 "
             "-loadbit \"up 0x0 {build_name}.bit\" -file {build_name}.bin"]
        self.programmer = programmer
        self.add_platform_command("set_property INTERNAL_VREF 0.750 [get_iobanks 34]")

    def create_programmer(self):
        if self.programmer == "openocd":
            proxy="bscan_spi_{}.bit".format(self.device.split('-')[0])
            return OpenOCD(config="board/digilent_arty.cfg", flash_proxy_basename=proxy)
        elif self.programmer == "xc3sprog":
            return XC3SProg("nexys4")
        elif self.programmer == "vivado":
            return VivadoProgrammer(flash_part="n25q128-3.3v-spi-x1_x2_x4")
        else:
            raise ValueError("{} programmer is not supported"
                             .format(self.programmer))

Actually Xilinx pn should change too.

I just don't want to start changing things without a better understanding of all scripts involved.

Please if possible @cr1901 will appreciate your knowledge.

cr1901 commented 6 years ago

I will take a look early next week. Quad SPI flashing works on my end, but I also need to push some changes to openocd since it doesn't understand Spartan7 yet.

mhanuel26 commented 6 years ago

@cr1901 @mithro would you please kindly let me know if there is something at least working you can share with me or let me know about required changes to support S7 board? Anything I can move forward ? Will appreciate your support.

cr1901 commented 6 years ago

@mhanuel26 Sorry I forgot to update this thread. Basic Arty S7 functionality works, but I'm not prepared to merge it just yet (still haven't tested the DDR3). Re: the JTAG errors, they are ignorable... OpenOCD doesn't expect Spartan 7 part numbers, and so treats them as errors, but the actual programming works fine. I submitted a patch for Spartan 7 part numbers. I also intend to to submit arty-s7 config files upstream once this patch is accepted.

In the meantime, use the following instructions until everything's merged into master:

Merge/cherry-pick my arty_s7 branch of litex into your copy of litex.
Create the following two files under ~/.openocd. Make sure to create the intermediate directories as well:

interface/ftdi/arty_s7.cfg

interface ftdi
ftdi_vid_pid 0x0403 0x6010
# interface 1 is the uart
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0x0088 0x008b
reset_config none
adapter_khz 10000

board/arty_s7.cfg

source [find interface/ftdi/arty_s7.cfg]
source [find cpld/xilinx-xc7.cfg]
source [find cpld/jtagspi.cfg]

Clone this repo and place all of the *.bit files under ~/.litex. This step is required for writing to the SPI flash to work properly, and are called the flash proxies (see $proxy below). You want the bscan_spi_xc7s50.bit file specifically.

Once you've done these steps, openocd programming should just work.

Open On-Chip Debugger 0.10.0+dev-00307-gefe6991 (2018-02-22-09:58)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
jtagspi_program
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Info : Listening on port 3333 for gdb connections
Info : accepting 'telnet' connection on tcp/4444
loaded file C:/msys64/home/william/src/migen-arty/bscan_spi_xc7s50.bit to pld device 0 in 0s 228013us
Info : JTAG tap: xc7.tap tap/device found: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
flash 'jtagspi' found at 0x00000000
auto erase enabled
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : sector 0 took 1882 ms
Info : sector 1 took 1929 ms
Info : sector 2 took 115 ms
Info : sector 3 took 113 ms
Info : sector 4 took 110 ms
Info : sector 5 took 109 ms
Info : sector 6 took 105 ms
Info : sector 7 took 103 ms
Info : sector 8 took 109 ms
Info : sector 9 took 106 ms
Info : sector 10 took 106 ms
Info : sector 11 took 108 ms
Info : sector 12 took 117 ms
Info : sector 13 took 107 ms
Info : sector 14 took 106 ms
Info : sector 15 took 112 ms
Info : sector 16 took 117 ms
Info : sector 17 took 103 ms
Info : sector 18 took 109 ms
Info : sector 19 took 113 ms
Info : sector 20 took 108 ms
Info : sector 21 took 113 ms
Info : sector 22 took 110 ms
Info : sector 23 took 106 ms
Info : sector 24 took 111 ms
Info : sector 25 took 105 ms
Info : sector 26 took 110 ms
Info : sector 27 took 118 ms
Info : sector 28 took 105 ms
Info : sector 29 took 112 ms
Info : sector 30 took 115 ms
Info : sector 31 took 104 ms
Info : sector 32 took 110 ms
Info : sector 33 took 118 ms
wrote 2228224 bytes from file //XUBUNTU-DTRAIN/william/Projects/migen_arty/blinky/blinky/blinky.bin in 22.104263s (98.443 KiB/s)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
read 2192012 bytes from file //XUBUNTU-DTRAIN/william/Projects/migen_arty/blinky/blinky/blinky.bin and flash bank 0 at offset 0x00000000 in 1.896108s (1128.964 KiB/s)
contents match
Info : dropped 'telnet' connection

Use init; pld load $jtag_addr $upload_file; exit for JTAG upload.
Use init; jtagspi_init $jtag_addr $proxy; jtagspi_program $upload_file $flash_addr; xc7_program xc7.tap; exit for writing to flash.

mhanuel26 commented 6 years ago

@cr1901 I follow your intructions but I think I am missing something

I update the litex under thirparty

~/Devel/Arty/src/litex-buildenv/third_party/litex$ git cherry-pick 4607e5323f96dce0f534bd3553bfb5c7e9428c7f
[detached HEAD c3e7bdc] boards/platforms: Add Arty S7 Board.
 Author: William D. Jones <thor0505@comcast.net>
 Date: Thu Jan 25 18:36:32 2018 -0500
 1 file changed, 116 insertions(+)
 create mode 100644 litex/boards/platforms/arty_s7.py

Then I create the openocd files and .litex directory with .bit files on it.

I am not sure of I need only the JTAG upload or the writing to flash, trying the JTAG upload give me the same errors as before, which I am not sure those are the ones you said to ignore.

~/Devel/Arty/src/litex-buildenv$ openocd -f ~/.openocd/board/arty_s7.cfg -c "init; pld load 0 build/arty_base_lm32/gateware/top.bit; exit"
Open On-Chip Debugger 0.10.0+dev-00167-g29cfe9c (2017-07-11-18:09)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
jtagspi_program
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Warn : JTAG tap: xc7.tap       UNEXPECTED: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Error: JTAG tap: xc7.tap expected 1 of 27: 0x0362e093 (mfg: 0x049 (Xilinx), part: 0x362e, ver: 0x0)
Error: JTAG tap: xc7.tap expected 2 of 27: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0)
Error: JTAG tap: xc7.tap expected 3 of 27: 0x0362c093 (mfg: 0x049 (Xilinx), part: 0x362c, ver: 0x0)
Error: JTAG tap: xc7.tap expected 4 of 27: 0x03632093 (mfg: 0x049 (Xilinx), part: 0x3632, ver: 0x0)
Error: JTAG tap: xc7.tap expected 5 of 27: 0x03631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x0)
Error: JTAG tap: xc7.tap expected 6 of 27: 0x03636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x0)
Error: JTAG tap: xc7.tap expected 7 of 27: 0x03647093 (mfg: 0x049 (Xilinx), part: 0x3647, ver: 0x0)
Error: JTAG tap: xc7.tap expected 8 of 27: 0x0364c093 (mfg: 0x049 (Xilinx), part: 0x364c, ver: 0x0)
Error: JTAG tap: xc7.tap expected 9 of 27: 0x03651093 (mfg: 0x049 (Xilinx), part: 0x3651, ver: 0x0)
Error: JTAG tap: xc7.tap expected 10 of 2: 0x03747093 (mfg: 0x049 (Xilinx), part: 0x3747, ver: 0x0)
Error: JTAG tap: xc7.tap expected 11 of 2: 0x03656093 (mfg: 0x049 (Xilinx), part: 0x3656, ver: 0x0)
Error: JTAG tap: xc7.tap expected 12 of 2: 0x03752093 (mfg: 0x049 (Xilinx), part: 0x3752, ver: 0x0)
Error: JTAG tap: xc7.tap expected 13 of 2: 0x03751093 (mfg: 0x049 (Xilinx), part: 0x3751, ver: 0x0)
Error: JTAG tap: xc7.tap expected 14 of 2: 0x03671093 (mfg: 0x049 (Xilinx), part: 0x3671, ver: 0x0)
Error: JTAG tap: xc7.tap expected 15 of 2: 0x036b3093 (mfg: 0x049 (Xilinx), part: 0x36b3, ver: 0x0)
Error: JTAG tap: xc7.tap expected 16 of 2: 0x036b7093 (mfg: 0x049 (Xilinx), part: 0x36b7, ver: 0x0)
Error: JTAG tap: xc7.tap expected 17 of 2: 0x036bb093 (mfg: 0x049 (Xilinx), part: 0x36bb, ver: 0x0)
Error: JTAG tap: xc7.tap expected 18 of 2: 0x036bf093 (mfg: 0x049 (Xilinx), part: 0x36bf, ver: 0x0)
Error: JTAG tap: xc7.tap expected 19 of 2: 0x03667093 (mfg: 0x049 (Xilinx), part: 0x3667, ver: 0x0)
Error: JTAG tap: xc7.tap expected 20 of 2: 0x03682093 (mfg: 0x049 (Xilinx), part: 0x3682, ver: 0x0)
Error: JTAG tap: xc7.tap expected 21 of 2: 0x03687093 (mfg: 0x049 (Xilinx), part: 0x3687, ver: 0x0)
Error: JTAG tap: xc7.tap expected 22 of 2: 0x03692093 (mfg: 0x049 (Xilinx), part: 0x3692, ver: 0x0)
Error: JTAG tap: xc7.tap expected 23 of 2: 0x03691093 (mfg: 0x049 (Xilinx), part: 0x3691, ver: 0x0)
Error: JTAG tap: xc7.tap expected 24 of 2: 0x03696093 (mfg: 0x049 (Xilinx), part: 0x3696, ver: 0x0)
Error: JTAG tap: xc7.tap expected 25 of 2: 0x036d5093 (mfg: 0x049 (Xilinx), part: 0x36d5, ver: 0x0)
Error: JTAG tap: xc7.tap expected 26 of 2: 0x036d9093 (mfg: 0x049 (Xilinx), part: 0x36d9, ver: 0x0)
Error: JTAG tap: xc7.tap expected 27 of 2: 0x036db093 (mfg: 0x049 (Xilinx), part: 0x36db, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
loaded file build/arty_base_lm32/gateware/top.bit to pld device 0 in 1s 852059us

I have try the command using openocd directly as above and also by doing it with make gateware-load which uses

openocd -f board/digilent_arty.cfg -c "init; pld load 0 build/arty_base_lm32//gateware/top.bit; exit"

with same results, the above digilent_arty.cfg do the same as your two openocd files I guess

cat /usr/local/share/openocd/scripts/board/digilent_arty.cfg 
#
# Digilent Arty with Xilinx Artix-7 FPGA
#
# http://store.digilentinc.com/arty-artix-7-fpga-development-board-for-makers-and-hobbyists/
#

# iManufacturer           1 Digilent
# iProduct                2 Digilent USB Device
# iSerial                 3 210319A28C7F

interface ftdi
ftdi_device_desc "Digilent USB Device"
ftdi_vid_pid 0x0403 0x6010
# channel 1 does not have any functionality
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0x0088 0x008b
reset_config none
adapter_khz 10000

source [find cpld/xilinx-xc7.cfg]
source [find cpld/jtagspi.cfg]

I haven't try the writing to flash since I am not sure which values should have $flash_addr and $upload_file, I understand the $proxy should be bscan_spi_xc7s50.bit

Would you kindly please let me know where is my error?

cr1901 commented 6 years ago

Okay, let's focus on this one at a time.

I am not sure of I need only the JTAG upload or the writing to flash, trying the JTAG upload give me the same errors as before, which I am not sure those are the ones you said to ignore.

You can ignore all errors of the form:

Warn : JTAG tap: xc7.tap       UNEXPECTED: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Error: JTAG tap: xc7.tap expected 1 of 27: 0x0362e093 (mfg: 0x049 (Xilinx), part: 0x362e, ver: 0x0)
...

Depsite the fact they say Error, they are safe to ignore in your/my case. Whenever openocd devs gets around to looking at my patch, this will be fixed in the openocd tree.

loaded file build/arty_base_lm32/gateware/top.bit to pld device 0 in 1s 852059us

This tells me your command succeeded :).

with same results, the above digilent_arty.cfg do the same as your two openocd files I guess

I believe they are the same file; I instructed you to create a separate file just in case we have to change the arty_s7 file later. Additionally, the digilent_arty.cfg file is a patch from @mithro; it is not provided by the openocd git repo.

That being said, I should probably commit both patches to @mithro's conda repo until my patch(es) gets accepted; openocd is... slow at receiving patches.

I haven't try the writing to flash since I am not sure which values should have $flash_addr and $upload_file, I understand the $proxy should be bscan_spi_xc7s50.bit

$flash_addr should be 0 (i.e. the FPGA starts loading the bitstream from address 0 in the flash). $upload_file should be build/arty_base_lm32//gateware/top.bin (bin is not a typo). $proxy is indeed correct :).

mhanuel26 commented 6 years ago

@cr1901 Thank you very much for your support,

Now I can upload the .bin using the second option to write to flash but the firmware-load hangs

(LX P=arty T=base F=micropython) mhanuel@debPLC:~/Devel/Arty/src/litex-buildenv$ openocd -f /home/mhanuel/.openocd/board/arty_s7.cfg -c "init; jtagspi_init 0 /home/mhanuel/.litex/bscan_spi_xc7s50.bit; jtagspi_program build/arty_base_lm32//gateware/top.bin 0; xc7_program xc7.tap; exit"
Open On-Chip Debugger 0.10.0+dev-00272-gedb679628-dirty (2018-01-19-15:08)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
jtagspi_program
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Warn : JTAG tap: xc7.tap       UNEXPECTED: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Error: JTAG tap: xc7.tap expected 1 of 27: 0x0362e093 (mfg: 0x049 (Xilinx), part: 0x362e, ver: 0x0)
Error: JTAG tap: xc7.tap expected 2 of 27: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0)
Error: JTAG tap: xc7.tap expected 3 of 27: 0x0362c093 (mfg: 0x049 (Xilinx), part: 0x362c, ver: 0x0)
Error: JTAG tap: xc7.tap expected 4 of 27: 0x03632093 (mfg: 0x049 (Xilinx), part: 0x3632, ver: 0x0)
Error: JTAG tap: xc7.tap expected 5 of 27: 0x03631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x0)
Error: JTAG tap: xc7.tap expected 6 of 27: 0x03636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x0)
Error: JTAG tap: xc7.tap expected 7 of 27: 0x03647093 (mfg: 0x049 (Xilinx), part: 0x3647, ver: 0x0)
Error: JTAG tap: xc7.tap expected 8 of 27: 0x0364c093 (mfg: 0x049 (Xilinx), part: 0x364c, ver: 0x0)
Error: JTAG tap: xc7.tap expected 9 of 27: 0x03651093 (mfg: 0x049 (Xilinx), part: 0x3651, ver: 0x0)
Error: JTAG tap: xc7.tap expected 10 of 2: 0x03747093 (mfg: 0x049 (Xilinx), part: 0x3747, ver: 0x0)
Error: JTAG tap: xc7.tap expected 11 of 2: 0x03656093 (mfg: 0x049 (Xilinx), part: 0x3656, ver: 0x0)
Error: JTAG tap: xc7.tap expected 12 of 2: 0x03752093 (mfg: 0x049 (Xilinx), part: 0x3752, ver: 0x0)
Error: JTAG tap: xc7.tap expected 13 of 2: 0x03751093 (mfg: 0x049 (Xilinx), part: 0x3751, ver: 0x0)
Error: JTAG tap: xc7.tap expected 14 of 2: 0x03671093 (mfg: 0x049 (Xilinx), part: 0x3671, ver: 0x0)
Error: JTAG tap: xc7.tap expected 15 of 2: 0x036b3093 (mfg: 0x049 (Xilinx), part: 0x36b3, ver: 0x0)
Error: JTAG tap: xc7.tap expected 16 of 2: 0x036b7093 (mfg: 0x049 (Xilinx), part: 0x36b7, ver: 0x0)
Error: JTAG tap: xc7.tap expected 17 of 2: 0x036bb093 (mfg: 0x049 (Xilinx), part: 0x36bb, ver: 0x0)
Error: JTAG tap: xc7.tap expected 18 of 2: 0x036bf093 (mfg: 0x049 (Xilinx), part: 0x36bf, ver: 0x0)
Error: JTAG tap: xc7.tap expected 19 of 2: 0x03667093 (mfg: 0x049 (Xilinx), part: 0x3667, ver: 0x0)
Error: JTAG tap: xc7.tap expected 20 of 2: 0x03682093 (mfg: 0x049 (Xilinx), part: 0x3682, ver: 0x0)
Error: JTAG tap: xc7.tap expected 21 of 2: 0x03687093 (mfg: 0x049 (Xilinx), part: 0x3687, ver: 0x0)
Error: JTAG tap: xc7.tap expected 22 of 2: 0x03692093 (mfg: 0x049 (Xilinx), part: 0x3692, ver: 0x0)
Error: JTAG tap: xc7.tap expected 23 of 2: 0x03691093 (mfg: 0x049 (Xilinx), part: 0x3691, ver: 0x0)
Error: JTAG tap: xc7.tap expected 24 of 2: 0x03696093 (mfg: 0x049 (Xilinx), part: 0x3696, ver: 0x0)
Error: JTAG tap: xc7.tap expected 25 of 2: 0x036d5093 (mfg: 0x049 (Xilinx), part: 0x36d5, ver: 0x0)
Error: JTAG tap: xc7.tap expected 26 of 2: 0x036d9093 (mfg: 0x049 (Xilinx), part: 0x36d9, ver: 0x0)
Error: JTAG tap: xc7.tap expected 27 of 2: 0x036db093 (mfg: 0x049 (Xilinx), part: 0x36db, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : Listening on port 3333 for gdb connections
loaded file /home/mhanuel/.litex/bscan_spi_xc7s50.bit to pld device 0 in 0s 213319us
Info : JTAG tap: xc7.tap tap/device found: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Warn : JTAG tap: xc7.tap       UNEXPECTED: 0x0362f093 (mfg: 0x049 (Xilinx), part: 0x362f, ver: 0x0)
Error: JTAG tap: xc7.tap expected 1 of 27: 0x0362e093 (mfg: 0x049 (Xilinx), part: 0x362e, ver: 0x0)
Error: JTAG tap: xc7.tap expected 2 of 27: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0)
Error: JTAG tap: xc7.tap expected 3 of 27: 0x0362c093 (mfg: 0x049 (Xilinx), part: 0x362c, ver: 0x0)
Error: JTAG tap: xc7.tap expected 4 of 27: 0x03632093 (mfg: 0x049 (Xilinx), part: 0x3632, ver: 0x0)
Error: JTAG tap: xc7.tap expected 5 of 27: 0x03631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x0)
Error: JTAG tap: xc7.tap expected 6 of 27: 0x03636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x0)
Error: JTAG tap: xc7.tap expected 7 of 27: 0x03647093 (mfg: 0x049 (Xilinx), part: 0x3647, ver: 0x0)
Error: JTAG tap: xc7.tap expected 8 of 27: 0x0364c093 (mfg: 0x049 (Xilinx), part: 0x364c, ver: 0x0)
Error: JTAG tap: xc7.tap expected 9 of 27: 0x03651093 (mfg: 0x049 (Xilinx), part: 0x3651, ver: 0x0)
Error: JTAG tap: xc7.tap expected 10 of 2: 0x03747093 (mfg: 0x049 (Xilinx), part: 0x3747, ver: 0x0)
Error: JTAG tap: xc7.tap expected 11 of 2: 0x03656093 (mfg: 0x049 (Xilinx), part: 0x3656, ver: 0x0)
Error: JTAG tap: xc7.tap expected 12 of 2: 0x03752093 (mfg: 0x049 (Xilinx), part: 0x3752, ver: 0x0)
Error: JTAG tap: xc7.tap expected 13 of 2: 0x03751093 (mfg: 0x049 (Xilinx), part: 0x3751, ver: 0x0)
Error: JTAG tap: xc7.tap expected 14 of 2: 0x03671093 (mfg: 0x049 (Xilinx), part: 0x3671, ver: 0x0)
Error: JTAG tap: xc7.tap expected 15 of 2: 0x036b3093 (mfg: 0x049 (Xilinx), part: 0x36b3, ver: 0x0)
Error: JTAG tap: xc7.tap expected 16 of 2: 0x036b7093 (mfg: 0x049 (Xilinx), part: 0x36b7, ver: 0x0)
Error: JTAG tap: xc7.tap expected 17 of 2: 0x036bb093 (mfg: 0x049 (Xilinx), part: 0x36bb, ver: 0x0)
Error: JTAG tap: xc7.tap expected 18 of 2: 0x036bf093 (mfg: 0x049 (Xilinx), part: 0x36bf, ver: 0x0)
Error: JTAG tap: xc7.tap expected 19 of 2: 0x03667093 (mfg: 0x049 (Xilinx), part: 0x3667, ver: 0x0)
Error: JTAG tap: xc7.tap expected 20 of 2: 0x03682093 (mfg: 0x049 (Xilinx), part: 0x3682, ver: 0x0)
Error: JTAG tap: xc7.tap expected 21 of 2: 0x03687093 (mfg: 0x049 (Xilinx), part: 0x3687, ver: 0x0)
Error: JTAG tap: xc7.tap expected 22 of 2: 0x03692093 (mfg: 0x049 (Xilinx), part: 0x3692, ver: 0x0)
Error: JTAG tap: xc7.tap expected 23 of 2: 0x03691093 (mfg: 0x049 (Xilinx), part: 0x3691, ver: 0x0)
Error: JTAG tap: xc7.tap expected 24 of 2: 0x03696093 (mfg: 0x049 (Xilinx), part: 0x3696, ver: 0x0)
Error: JTAG tap: xc7.tap expected 25 of 2: 0x036d5093 (mfg: 0x049 (Xilinx), part: 0x36d5, ver: 0x0)
Error: JTAG tap: xc7.tap expected 26 of 2: 0x036d9093 (mfg: 0x049 (Xilinx), part: 0x36d9, ver: 0x0)
Error: JTAG tap: xc7.tap expected 27 of 2: 0x036db093 (mfg: 0x049 (Xilinx), part: 0x36db, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
flash 'jtagspi' found at 0x00000000
auto erase enabled
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : sector 0 took 1768 ms
Info : sector 1 took 1735 ms
Info : sector 2 took 120 ms
Info : sector 3 took 110 ms
Info : sector 4 took 115 ms
Info : sector 5 took 108 ms
Info : sector 6 took 117 ms
Info : sector 7 took 111 ms
Info : sector 8 took 112 ms
Info : sector 9 took 123 ms
Info : sector 10 took 116 ms
Info : sector 11 took 127 ms
Info : sector 12 took 126 ms
Info : sector 13 took 120 ms
Info : sector 14 took 123 ms
Info : sector 15 took 112 ms
Info : sector 16 took 122 ms
Info : sector 17 took 111 ms
Info : sector 18 took 113 ms
Info : sector 19 took 111 ms
Info : sector 20 took 113 ms
Info : sector 21 took 114 ms
Info : sector 22 took 99 ms
Info : sector 23 took 104 ms
Info : sector 24 took 110 ms
Info : sector 25 took 114 ms
Info : sector 26 took 105 ms
Info : sector 27 took 105 ms
Info : sector 28 took 110 ms
Info : sector 29 took 113 ms
Info : sector 30 took 114 ms
Info : sector 31 took 118 ms
Info : sector 32 took 101 ms
Info : sector 33 took 109 ms
wrote 2228224 bytes from file build/arty_base_lm32//gateware/top.bin in 21.206606s (102.610 KiB/s)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
read 2192012 bytes from file build/arty_base_lm32//gateware/top.bin and flash bank 0 at offset 0x00000000 in 1.884507s (1135.913 KiB/s)
contents match

After that I have tried to reset the board, also unplug, I know the .bin is programmed since the demo has gone, but when I do make firmware-load, at the end I got the following which don't finish.

mkdir -p build/arty_base_lm32/
time python -u ./make.py --platform=arty --target=base --cpu-type=lm32 --iprange=192.168.100 -Ob toolchain_path //opt/Xilinx/    --no-compile-gateware \
    2>&1 | tee -a /home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32//output.20180227-233402.log; (exit ${PIPESTATUS[0]})
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/libcompiler_rt'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/libcompiler_rt'
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/libbase'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/libbase'
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/libnet'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/libnet'
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/bios'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/bios'
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/uip'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/uip'
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/firmware'
bash /home/mhanuel/Devel/Arty/src/litex-buildenv/firmware/version_data.sh
# Check the version files exist
[ -e /home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/include/../..//software/firmware/version_data.h ]
[ -e /home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/include/../..//software/firmware/version_data.c ]
make[1]: Leaving directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/firmware'

real    0m0.862s
user    0m0.768s
sys 0m0.024s
flterm --port=/dev/ttyUSB1 --kernel=build/arty_base_lm32//software/micropython/firmware.bin --speed=115200
[FLTERM] Starting...
targets/arty/Makefile.mk:28: recipe for target 'firmware-load-arty' failed
make: *** [firmware-load-arty] Interrupt

I have tried the same taken off the CR_RST jumper with same results.

Is the make gateware ok with documentation here, i.e. PLATFORM=arty, since your litex has include a new arty_s7.py platform file?

How can I debug this further?

Will appreciate your comments.

mhanuel26 commented 6 years ago

Hi @cr1901 , I did all the steps as suggested and bitstream loads now, but I cannot load the FuPy firmware. Could you please let me know what am I missing here?

Thank you in advance,

cr1901 commented 6 years ago

@mhanuel26 I do not know what is wrong and have not had the opportunity to check. It looks like a Makefile bug tho. I don't see an error reason however.

I've had issues w/ loading firmware images on my end as well (the Makefile expects to load an image.bin file, but the image file that is generated has a different name), but I'm uncertain if my issue is related.

mhanuel26 commented 6 years ago

@cr1901, thank you for letting me know, I thought it was only me. Witt my limited knowledge on the project I will try to understand better the problem, please just let me know if you succeed.

mhanuel26 commented 6 years ago

@cr1901 @mithro I have successfully run micropython firmware on Arty S7, at least a hello world

flterm --port=/dev/ttyUSB1 --kernel=build/arty_base_lm32//software/micropython/firmware.bin --speed=115200
[FLTERM] Starting...
        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
      SoC BIOS / CPU:LM32
(c) Copyright 2012-2018 Enjoy-Digital
(c) Copyright 2007-2018 M-Labs Limited
Built Feb 14 2018 04:16:22

BIOS CRC passed (824b9f3e)
Initializing SDRAM...
Memtest OK
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
[FLTERM] Received firmware download request from the device.
[FLTERM] Uploading kernel (167816 bytes)...
[FLTERM] Upload complete (7.6KB/s).
[FLTERM] Booting the device.
[FLTERM] Done.
Executing booted program at 0x40000000
MicroPython v1.8.7-465-g7a4245d on 2018-03-02; litex with lm32
>>> print('Hello World')
Hello World
>>>

This is what I did.

I recompile using PLATFORM=arty doing some changes to original arty files, I know it should be a new platform such arty_s7, but that might be better specified by you I guess.

First I took your arty s7 platform file and replace your original file with this modifications.

The clk100 have some conflict with VCCOs, this was the error

ERROR: [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34. For example, the following two ports in this bank have conflicting VCCOs: ddram_dqs_p[0] (DIFF_SSTL135, requiring VCCO=1.350) and clk100 (LVCMOS33, requiring VCCO=3.300) So I change the line clk100 to

("clk100", 0, Pins("R2"), IOStandard("SSTL135")),

I remove the ethernet definition for 25 MHz clock in targets/base.py file since Arty S7 don't need it and complain with your file.

I add this missing part in your Platform class

` # From https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf

17536096 bits == 2192012 == 0x21728c -- Therefore 0x220000

# 7S50 same Configuration Bitstream Length as 7A35T
gateware_size = 0x220000

# Cypress 'sp s25fl128' (ID 0x00182001)
# FIXME: Create a "spi flash module" object in the same way we have SDRAM
# module objects.
spiflash_model = "S25FL128S"
spiflash_read_dummy_bits = 10
spiflash_clock_div = 4
spiflash_total_size = int((128/8)*1024*1024) # 128Mbit
spiflash_page_size = 256
spiflash_sector_size = 0x10000`

The sector size of this memory is also 64K, the only thing that makes me doubt is that it has an hybrid sector scheme, there are 32 4k sectors, more info on page 44 here

After this I load bitstream as

openocd -f /home/mhanuel/.openocd/board/arty_s7.cfg -c "init; jtagspi_init 0 /home/mhanuel/.litex/bscan_spi_xc7s50.bit; jtagspi_program build/arty_base_lm32//gateware/top.bin 0; xc7_program xc7.tap; exit"

then make firmware-load do the job as shown above.

Just one question, to create a new target it just suffice to create i.e. the arty_s7 folder with base.py on it and also the platform file arty_s7.py and change PLATFORM=arty_s7 ?

cr1901 commented 6 years ago

Just one question, to create a new target it just suffice to create i.e. the arty_s7 folder with base.py on it and also the platform file arty_s7.py and change PLATFORM=arty_s7?

Yes, that is sufficient, but please don't do that. First off, I'm surprised the DDR controller worked from Arty A7 on Arty S7 without changes. Second, I'm concerned about this error:

ERROR: [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34. For example, the following two ports in this bank have conflicting VCCOs: ddram_dqs_p[0] (DIFF_SSTL135, requiring VCCO=1.350) and clk100 (LVCMOS33, requiring VCCO=3.300

This means I got something wrong in the platform file for the DDR RAM that I need to check before I commit. Your change worked, but I think it would stop working for more complex designs; you're using an I/O standard meant for differential I/O to drive the system clock!

mhanuel26 commented 6 years ago

Well, I did the change after looking at the schematic, if you look for the Arty A7 you will find clock is LVCMOS33 arty_a7_clock

And my Rev b of Arty S7 is arty_s7

The upper rail is actually 1.35 volts.

It's not like I can test too much right now as the default micropython compile but I tried testing the leds using


import litex
led1 = litex.LED(1)

it should turn on LED2 but it does nothing, same for other numbers.

Do you know how to add standard libraries such time to litex micropython?

mhanuel26 commented 6 years ago

Sorry I click close by accident while posting a replay...

@cr1901 When you said

I'm surprised the DDR controller worked from Arty A7 on Arty S7 without changes.

Shouldn't be that the case if both DDR3 memory are same P/N MT41K128M16JT-125 and looking at the datasheet the configuration seems the same?

cr1901 commented 6 years ago

@mhanuel26 You are 100% correct re: the clock, I apologize. And... that is weird to me, but yes that is a bug w/ my code and I'll fix it, tyvm!

I sadly don't know how to add such libraries to micropython :(. I'm working on finalizing the arty_s7 platform this morning.

mhanuel26 commented 6 years ago

I am happy to contribute, I understand you said about the led that is a bug right?

Ok I will wait for your changes, could you please kindly let me know whenever you do the commit.

Thanks for everything.

cr1901 commented 6 years ago

@mhanuel26

I understand you said about the led that is a bug right?

I'm not sure what's going on with the LEDs. After I finalize arty_s7, could you go ahead and push your changes to Github (including platform/arty_s7.py and targets/arty_s7/base.py, and I'll take a look myself?

Btw, out of curiosity, how'd you fix this error described above?

make[1]: Leaving directory '/home/mhanuel/Devel/Arty/src/litex-buildenv/build/arty_base_lm32/software/firmware'

real    0m0.862s
user    0m0.768s
sys 0m0.024s
flterm --port=/dev/ttyUSB1 --kernel=build/arty_base_lm32//software/micropython/firmware.bin --speed=115200
[FLTERM] Starting...
targets/arty/Makefile.mk:28: recipe for target 'firmware-load-arty' failed
make: *** [firmware-load-arty] Interrupt

mhanuel26 commented 6 years ago

Ok I commit to my fork what I have, just because you ask remember I use the Arty files instead of creating new ones.

After you do the changes, I first do

make gateware 
scripts/build-micropython.sh

Then I don't do make gateware-load since that seems to do nothing, instead I manually load it using your version of openocd command

openocd -f /home/mhanuel/.openocd/board/arty_s7.cfg -c "init; jtagspi_init 0 /home/mhanuel/.litex/bscan_spi_xc7s50.bit; jtagspi_program build/arty_base_lm32//gateware/top.bin 0; xc7_program xc7.tap; exit"

That ends up with something like

Info : Found flash device 'sp s25fl128' (ID 0x00182001)
flash 'jtagspi' found at 0x00000000
auto erase enabled
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
Info : sector 0 took 1868 ms
Info : sector 1 took 1800 ms
Info : sector 2 took 119 ms
Info : sector 3 took 112 ms
Info : sector 4 took 117 ms
Info : sector 5 took 114 ms
Info : sector 6 took 123 ms
Info : sector 7 took 127 ms
Info : sector 8 took 123 ms
Info : sector 9 took 156 ms
Info : sector 10 took 130 ms
Info : sector 11 took 121 ms
Info : sector 12 took 119 ms
Info : sector 13 took 127 ms
Info : sector 14 took 137 ms
Info : sector 15 took 121 ms
Info : sector 16 took 120 ms
Info : sector 17 took 116 ms
Info : sector 18 took 131 ms
Info : sector 19 took 115 ms
Info : sector 20 took 121 ms
Info : sector 21 took 120 ms
Info : sector 22 took 111 ms
Info : sector 23 took 119 ms
Info : sector 24 took 118 ms
Info : sector 25 took 122 ms
Info : sector 26 took 121 ms
Info : sector 27 took 115 ms
Info : sector 28 took 132 ms
Info : sector 29 took 119 ms
Info : sector 30 took 131 ms
Info : sector 31 took 126 ms
Info : sector 32 took 122 ms
Info : sector 33 took 124 ms
wrote 2228224 bytes from file build/arty_base_lm32//gateware/top.bin in 22.004265s (98.890 KiB/s)
Info : Found flash device 'sp s25fl128' (ID 0x00182001)
read 2192012 bytes from file build/arty_base_lm32//gateware/top.bin and flash bank 0 at offset 0x00000000 in 1.916772s (1116.793 KiB/s)
contents match

Thereafter I load micropython as

make firmware-load

Notice that after bitstream is loaded only the red PWR led is on. I have some problems as you that I solve removing Digilent Adept udev rules.

Verify after you connect the board, for some reason I really don't understand, the Digilent Adept rules was breaking things, for example when it was causing problems dmesg output was

[58978.995042] usb 1-8: Manufacturer: Digilent
[58978.995044] usb 1-8: SerialNumber: 210352A6BD8C
[58978.998510] ftdi_sio 1-8:1.0: FTDI USB Serial Device converter detected
[58978.998630] usb 1-8: Detected FT2232H
[58978.998953] usb 1-8: FTDI USB Serial Device converter now attached to ttyUSB1
[58979.001718] ftdi_sio 1-8:1.1: FTDI USB Serial Device converter detected
[58979.001809] usb 1-8: Detected FT2232H
[58979.002006] usb 1-8: FTDI USB Serial Device converter now attached to ttyUSB2
[58979.024729] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[58979.024796] ftdi_sio 1-8:1.0: device disconnected

As you can see ttyUSB1 was disconnecting during the process.

This might or not be your case but I comment file /etc/udev/rules.d/52-digilent-usb.rules

#ATTR{idVendor}=="1443", MODE:="666"
#ACTION=="add", ATTR{idVendor}=="0403", ATTR{manufacturer}=="Digilent", MODE:="666", RUN+="/usr/sbin/dftdrvdtch %s{busnum} %s{devnum}"

After that reload udev rules (i.e. debian)

sudo udevadm control --reload-rules && sudo udevadm trigger

dmesg | tail in my working board is

mhanuel@debPLC:~/Devel/Arty/src/litex-buildenv$ sudo dmesg | tail
[195823.244688] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[195823.244692] usb 1-7: Product: Digilent Adept USB Device
[195823.244695] usb 1-7: Manufacturer: Digilent
[195823.244698] usb 1-7: SerialNumber: 210352A6BD8C
[195823.248473] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
[195823.248601] usb 1-7: Detected FT2232H
[195823.248805] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
[195823.251535] ftdi_sio 1-7:1.1: FTDI USB Serial Device converter detected
[195823.251643] usb 1-7: Detected FT2232H
[195823.251871] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB1

Hope this helps.

cr1901 commented 6 years ago

Okay this looks like a Linux issue; I'm on Windows, sadly :(.

So a few other things I forgot to mention:

Shouldn't be that the case if both DDR3 memory are same P/N MT41K128M16JT-125 and looking at the datasheet the configuration seems the same?

I wasn't sure that the bitslip/delay constants would be the same between both boards, but I did a test, and bitslip of 3, and delay of 14 works fine for both boards (.. means error). However, use a delay of 17 for the Arty S7- it is in the middle of the sampling window/has the highest error tolerance. _I'm now confident artys7 works properly, so feel free to create a platform/target file/file a PR. All I had to do was change the clock in my file and things worked!

I add this missing part in your Platform class ...

gateware_size = 0x220000 ...

spiflash_model = "S25FL128S" spiflash_read_dummy_bits = 10 spiflash_clock_div = 4 spiflash_total_size = int((128/8)10241024) # 128Mbit spiflash_page_size = 256 spiflash_sector_size = 0x10000`

These are all litex-buildenv/HDMI2USB specific code (not in litex), so it's good you added them even though my file didn't have them. You will also need to put the linked constants in your target/arty_s7/base.py file; the firmware requires them to compile successfully. But I assume since you got a successful compile you already did that :P.

mhanuel26 commented 6 years ago

@cr1901 Thank you for the comments,

At the end you solve the issue on your windows machine? I have windows 10 machine with vivado but not sure how to setup litex there to replicate the issue.

Did you figure out what might be the LED problem?

mhanuel26 commented 6 years ago

@cr1901 , @mithro

Ok, just found the LED problem and with some changes LEDs works now.

I did the following changes manually on the code, not sure if it's the correct way to fix them, since that for sure would break micropython.

Under third_party/micropython/litex_leds.c original code is

#ifndef CSR_CAS_BASE
static inline unsigned char cas_leds_out_read(void) {
    return 0;
}

static inline void cas_leds_out_write(unsigned char value) {
}
#endif

but after looking at my generated folder and trying to locate the CSR_CAS_BASE definition, I end up thinking that something mess up, the functions defined in csr.h are called _leds_outread and _leds_outwrite , that is without the starting _cas__. I also change the #ifndef CSR_CAS_BASE in litex_leds.c for _CSR_LEDSBASE which is the definition I found under csr.h, such as

/* leds */
#define CSR_LEDS_BASE 0xe0006800
#define CSR_LEDS_OUT_ADDR 0xe0006800
#define CSR_LEDS_OUT_SIZE 1
static inline unsigned char leds_out_read(void) {
    unsigned char r = MMPTR(0xe0006800);
    return r;
}
static inline void leds_out_write(unsigned char value) {
    MMPTR(0xe0006800) = value;
}

After changing those references my Arty_S7 leds works.

What would be the correct way to fix this?

fupy / issues-wiki

Micropython and Arty S7 support #9

17536096 bits == 2192012 == 0x21728c -- Therefore 0x220000