Author Topic: Qmtech Artix 7 Wukong board  (Read 13273 times)

0 Members and 1 Guest are viewing this topic.

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #25 on: August 08, 2021, 12:03:47 pm »
small progress applying the changes. I've edited the board, platform, and dts files but cant figure out where to put the host and wrapper files and where and how to apply the patch.
What directory does the patch need to be applied in? Where do the new files need to be copied to?

The new python files I was putting straight into the linux-on-litex-vexriscv directory (where make.py lives), it's not currently properly 'packaged'.

The patch is for the Linux kernel (it adds the driver) so is applied in the linux source tree; it might integrable in linux-on-litex-vexriscv and/or buildroot but I was rebuilding the kernel from an external tree.

I'll attach to this message the patch I was using to the platform/target. You may have to do some changes to make.py to force the enablement of the pmod and the device.

As I said - it's still quite rough, I switched to USB and didn't clean up the prototype :-(

 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #26 on: August 08, 2021, 06:44:08 pm »
Just managed to boot linux-on-litex-vexriscv and it shows the framebuffer penguin with a strange byte reversal on the penguin logo. The Litex console appears without a problem when running the standard bios.
I've no idea where the source of this problem is.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: Qmtech Artix 7 Wukong board
« Reply #27 on: August 08, 2021, 07:52:56 pm »
Ahh, the good all Little-Endian - Big-Endian pixel packing/addressing problem...
« Last Edit: August 08, 2021, 09:48:09 pm by BrianHG »
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #28 on: August 08, 2021, 10:35:28 pm »
Ahh, the good all Little-Endian - Big-Endian pixel packing/addressing problem...
All the bits are there but not necessarily in the right order ;-) At least the colours are right, on another board I had the colours all mixed up.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: Qmtech Artix 7 Wukong board
« Reply #29 on: August 08, 2021, 10:42:51 pm »
What was the color like on the other board?
Maybe the byte addressing across 2-4 pixels was correct, but the color palette within each 32 bit word had the Endian problem messing up the color swapping around the possible combinations ARGB/ABGR/RGBA/BGRA.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #30 on: August 08, 2021, 10:57:38 pm »
What was the color like on the other board?
Maybe the byte addressing across 2-4 pixels was correct, but the color palette within each 32 bit word had the Endian problem messing up the color swapping around the possible combinations ARGB/ABGR/RGBA/BGRA.
I took a photo at the time, I think it was simply red and blue swapped in this instance.  Very cold looking penguins.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: Qmtech Artix 7 Wukong board
« Reply #31 on: August 08, 2021, 11:13:03 pm »
Remember, depending on how the color information is packed, it may be a 32bit word being addressed with the 8 individual bytes in the wrong order, again an Endian issue.

With your other graphic, it's like 128bit chunks where every 8 bits are reversed inside, IE: addressed left to right instead or right to left.  Again, a larger width of the same Endina issue.  You fixed the 8 byte color palette order, but, reversed all the bytes in a chunk or 128 bits.  By the way, 128 bits is the 'Burst Size' used in a 16 bit DDR3 ram chip, as on my other thread with my DDR3 ram controller, I had this Endian addressing problem way back in the beginning of development.
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #32 on: August 09, 2021, 06:09:12 am »
Just managed to boot linux-on-litex-vexriscv and it shows the framebuffer penguin with a strange byte reversal on the penguin logo. The Litex console appears without a problem when running the standard bios.

Never seen that on my side. Is that a standard Litex SoC ? Do you use native or wishbone for the memory ? (mine is native, I vaguely recall a discussion on endianess and the framebuffer some time back on IRC but I'm not sure).
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #33 on: August 09, 2021, 06:37:23 am »
Never seen that on my side. Is that a standard Litex SoC ? Do you use native or wishbone for the memory ? (mine is native, I vaguely recall a discussion on endianess and the framebuffer some time back on IRC but I'm not sure).

Litex was installed following the instructions here: https://github.com/enjoy-digital/litex/wiki/Installation
Linux was installed by following the instructions here: https://github.com/litex-hub/linux-on-litex-vexriscv
I dont know the answers to your memory question.
I have changed the supplied qmtech_wukong configuration files and saved them as qmtech_wukong_02
The changes are in the pin constraints and the addition of a micro SD card socket.
The DVI is set to 800x600 - I'll try it at 640x480 just in case. I haven't seen text yet from the linux system, and so dont know if it would appear properly. I'm wondering if its just the penguin rendering that is wrong. I could poke some bytes into the screen memory as an experiment.

I managed to get ethernet running with DHCP but not qspi, sdcard, or gpio. I haven't tried PS/2 yet.
I ran buildroot and the new image acted the same.
bootlog attached.
Kind regards, David.

edit: at 640x480 the problem persists.
« Last Edit: August 09, 2021, 08:05:02 am by djrm »
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #34 on: August 09, 2021, 09:02:52 am »
I dont know the answers to your memory question.

It's likely to be wishbone instead of native, as IIRC you cannot have L2 cache and native litedram - and your log says:

Code: [Select]
CPU: VexRiscv SMP-LINUX @ 100MHz
BUS: WISHBONE 32-bit @ 4GiB
CSR: 32-bit data
ROM: 64KiB
SRAM: 8KiB
L2: 2KiB
SDRAM: 262144KiB 16-bit @ 800MT/s (CL-6 CWL-5)

I suggest trying again with no L2 cache, and checking in the output log of Litex (during build) how memory is handled.

It's weird that you have L2 cache as the default configuration for Litex in linux-on-litex-vexriscv (using the make.py script) should not use it on this board by default. But then, it shouldn't add SRAM either I think. (upd) now that I double-check, it seems the make.py in linux-on-litex-vexriscv wasn't properly updated; it specifies a non-zero L2 cache size ((upd2)no sure why you get the SRAM apparently I have the SRAM as well, never noticed it!). Mine look like this:

Code: [Select]
class Qmtech_WuKong(Board):
    SPIFLASH_PAGE_SIZE    = 256
    SPIFLASH_SECTOR_SIZE  = 64*kB
    SPIFLASH_DUMMY_CYCLES = 11
    soc_kwargs = {
        "sys_clk_freq": 100e6,
        "with_video_framebuffer": True,
        "video_timing": "800x600@60Hz",
        "ps2kbd": False,
        "ps2mou": False,
        "usb": True
    }
    def __init__(self):
        from litex_boards.targets import qmtech_wukong
        Board.__init__(self, qmtech_wukong.BaseSoC, soc_capabilities={
            # Communication
            "serial",
            "ethernet",
            # Storage
            #"spiflash",
            "sdcard",
            # GPIOs
            "leds",
            # Buses
            # Monitoring
            # Video
            "framebuffer",
            # 7-Series specific
            #"mmcm",
            "icap_bitstream",
        }, bitstream_ext=".bit")

OTOH, if you're generating the gateware directly from the target file, you probably need to add some options like
Code: [Select]
--l2-size 0 --integrated-sram-size 0
It's still a little bit bleeding-edge...
« Last Edit: August 09, 2021, 09:50:23 am by dolbeau »
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #35 on: August 09, 2021, 10:40:40 am »
I suggest trying again with no L2 cache, and checking in the output log of Litex (during build) how memory is handled.

With linux configured as below (with L2 cache removed) the boot logo appears properly.

Code: [Select]
class Qmtech_WuKong_02(Board):
    SPIFLASH_PAGE_SIZE    = 256
    SPIFLASH_SECTOR_SIZE  = 64*kB
    SPIFLASH_DUMMY_CYCLES = 11
    soc_kwargs = {
        "uart_baudrate": 3e6,
        "sys_clk_freq": 100e6,
        "with_video_framebuffer": True,
        "video_timing": "800x600@60Hz"
    }
    def __init__(self):
        from litex_boards.targets import qmtech_wukong_02
        Board.__init__(self, qmtech_wukong_02.BaseSoC, soc_capabilities={
            # Communication
            "serial",
            "ethernet",
            # Storage
            #"spiflash",
            ##"sdcard",
            # GPIOs
            "leds",
            # Buses
            # Monitoring
            # Video
            "framebuffer",
            # 7-Series specific
            #"mmcm",
            ##"icap_bitstream",
        }, bitstream_ext=".bit")

Boot log attached.
* runlog_2nd.txt (9.95 kB - downloaded 115 times.)

I've now reinstalled everything under /opt/Litex and made a new set of qmtech_wukong_02 board files. its a bit neater out of ~/

Now to try and sort out the sdcard or flash memory. Thanks for your help it is very much appreciated.
Kind regards, David.
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #36 on: August 09, 2021, 12:51:27 pm »
Now to try and sort out the sdcard or flash memory. Thanks for your help it is very much appreciated.

Got plenty of help for this forum myself, trying to pay it forward :-)

For the sdcard if you have the pins OK, it should be just adding a --with-sdcard to get the device in linux (it should be /dev/mmclbk0 IIRC). You can also try with SPI, but that's mostly to try in the BIOS as it won't work in Linux (the driver only knows about native SD mode).

Then if you have a FAT32 first partition with the proper files (the DTB, kernel, root filesystem image, etc.) on the sdcard, you can boot from it as well.

Then you can have another partition with the ext2/3/4 root filesystem and point to it in the Linux options in the DTS/DTB (replacing root=/dev/ram0 by e.g. root=/dev/mmcblk0b): once that work you can stop loading it from the BIOS to save memory. That's my 'work' config.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #37 on: August 11, 2021, 11:21:43 pm »
I have eventually got a working sdcard system, plenty of problems on the way, the main one being that the system doesnt like the 2GB microsdcard I have been testing with. I found this the long round way having build a pmod microsd interface and also finding in the process that J10 and J11 are transposed in the wukong board definition file. Now I have managed to build the donut demo program which eluded me before, and have managed to boot it from a new micro sd card. :-) next see if it works in Linux ...

A bit more tinkering and I can boot linux from SDcard, not able to see the sdcard device in /dev though.
booting from sdcard seems more reliable than tftp boot which was a bit hit and miss.
« Last Edit: August 12, 2021, 08:27:42 am by djrm »
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #38 on: August 12, 2021, 10:33:05 am »
Oups, the J10/J11 I forgot about - it's in my local tree but committed so didn't appear in the patch I posted, sorry.

For the sd-card in Linux you need  to use SD mode (so --with-sdcard not --with-spi-sdcard), and a kernel with the proper driver. The 'canonical' branch is litex-rebase on https://github.com/litex-hub/linux (i.e. https://github.com/litex-hub/linux/tree/litex-rebase. I don't know which commit the default buildroot kernel commit is using, or if it includes the latest driver for the latest gateware of the sd-card controller.
« Last Edit: August 12, 2021, 10:34:44 am by dolbeau »
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #39 on: August 12, 2021, 11:03:11 am »
Oups, the J10/J11 I forgot about - it's in my local tree but committed so didn't appear in the patch I posted, sorry.

For the sd-card in Linux you need  to use SD mode (so --with-sdcard not --with-spi-sdcard), and a kernel with the proper driver. The 'canonical' branch is litex-rebase on https://github.com/litex-hub/linux (i.e. https://github.com/litex-hub/linux/tree/litex-rebase. I don't know which commit the default buildroot kernel commit is using, or if it includes the latest driver for the latest gateware of the sd-card controller.

Not to worry, I had reverted to a pmod sdcard so I could put the LA onto the pins but since a new 16GB micro sdcard sorted the problem I have now reverted the platform file to the onboard sdcard socket and its working nicely in the bios. I suspected the buildroot needed changing to ebable the sdcard in Linux. I have 8 leds working on an expansion board too with the bios and demo programs. I'll try the linux kernel in your link when I work out how to,  Kind regards, David.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #40 on: August 12, 2021, 04:28:45 pm »
The supplied openocd configuration doesn't work on my Wukong board.
One of the problems is that the flash chip is not recognised by openocd.

I've built the current version but not installed it.
It is able to write to the flash chip but the command syntax has changed.
I doubt if the LItex will be able to use it.

Programmed the flash manually using these commands:
Code: [Select]
# instructions here: https://marc.info/?l=openocd-development&m=151002052505567&w=2
# build latest: Open On-Chip Debugger 0.11.0+dev-00294-g3d9534b8a-dirty (2021-08-12-16:54)
# program wukong flash: /opt/Litex/openocd/src/openocd -f openocd_xc7_ft232_new.cfg
# contents of openocd_xc7_ft232_new.cfg below:

adapter driver ftdi
ftdi vid_pid 0x0403 0x6014
ftdi channel 0
ftdi layout_init 0x00e8 0x60eb
reset_config none

#source [find cpld/xilinx-xc7.cfg]
source /opt/Litex/openocd/tcl/cpld/xilinx-xc7.cfg
#source [find cpld/jtagspi.cfg]
source /opt/Litex/openocd/tcl/cpld/jtagspi.cfg
adapter speed 25000

init
jtagspi_init 0 bscan_spi_xc7a100t.bit
jtagspi_program /opt/Litex/litex-boards/litex_boards/targets/build/qmtech_wukong_02/gateware/qmtech_wukong_02.bin 0
#xc7_program xc7.tap
exit

Does anybody know of a version of openocd that will 'just work' with the flash in the Wukong board, otherwise it looks as if a re-write of the python scripts is needed.
The flash id is 0x00186001, my disto supplies "Open On-Chip Debugger 0.10.0"
Kind regards, David.


Code: [Select]
david@I7MINT:/opt/Litex/litex-boards/litex_boards/targets$ /opt/Litex/openocd/src/openocd -f openocd_xc7_ft232_new.cfg
Open On-Chip Debugger 0.11.0+dev-00294-g3d9534b8a-dirty (2021-08-12-16:54)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi tdo_sample_edge falling"
Info : clock speed 25000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x13631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x1)
Info : JTAG tap: xc7.tap tap/device found: 0x13631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x1)
Info : Found flash device 'cyp s25fl128l' (ID 0x00186001)
Info : Found flash device 'cyp s25fl128l' (ID 0x00186001)
Info : Found flash device 'cyp s25fl128l' (ID 0x00186001)
Info : Found flash device 'cyp s25fl128l' (ID 0x00186001)
Info : sector 0 took 247 ms
Info : sector 1 took 261 ms
Info : sector 2 took 249 ms
Info : sector 3 took 245 ms
Info : sector 4 took 281 ms
Info : sector 5 took 273 ms
Info : sector 6 took 263 ms
Info : sector 7 took 256 ms
Info : sector 8 took 266 ms
Info : sector 9 took 265 ms
Info : sector 10 took 252 ms
Info : sector 11 took 258 ms
Info : sector 12 took 249 ms
Info : sector 13 took 253 ms
Info : sector 14 took 257 ms
Info : sector 15 took 245 ms
Info : sector 16 took 250 ms
Info : sector 17 took 247 ms
Info : sector 18 took 248 ms
Info : sector 19 took 235 ms
Info : sector 20 took 257 ms
Info : sector 21 took 252 ms
Info : sector 22 took 258 ms
Info : sector 23 took 240 ms
Info : sector 24 took 256 ms
Info : sector 25 took 256 ms
Info : sector 26 took 255 ms
Info : sector 27 took 247 ms
Info : sector 28 took 265 ms
Info : sector 29 took 251 ms
Info : sector 30 took 243 ms
Info : sector 31 took 251 ms
Info : sector 32 took 257 ms
Info : sector 33 took 257 ms
Info : sector 34 took 259 ms
Info : sector 35 took 249 ms
Info : sector 36 took 260 ms
Info : sector 37 took 263 ms
Info : sector 38 took 252 ms
Info : sector 39 took 250 ms
Info : sector 40 took 266 ms
Info : sector 41 took 257 ms
Info : sector 42 took 260 ms
Info : sector 43 took 247 ms
Info : sector 44 took 229 ms
Info : sector 45 took 242 ms
Info : sector 46 took 244 ms
Info : sector 47 took 238 ms
Info : sector 48 took 252 ms
Info : sector 49 took 260 ms
Info : sector 50 took 243 ms
Info : sector 51 took 237 ms
Info : sector 52 took 260 ms
Info : sector 53 took 249 ms
Info : sector 54 took 259 ms
Info : sector 55 took 259 ms
Info : sector 56 took 267 ms
Info : sector 57 took 262 ms
Info : sector 58 took 268 ms
Info : Found flash device 'cyp s25fl128l' (ID 0x00186001)
david@I7MINT:/opt/Litex/litex-boards/litex_boards/targets$
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #41 on: August 12, 2021, 04:33:27 pm »
Won't be able to help on that side, I've always programmed the board by hand with the Vivado HW manager (works fine for me, didn't look any further).
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #42 on: August 13, 2021, 12:14:33 pm »
Won't be able to help on that side, I've always programmed the board by hand with the Vivado HW manager (works fine for me, didn't look any further).

The changes needed to work with the latest openocd are pretty much all contained in the supplied .cfg files. I'll probably uninstall the old openocd and use the new, but at present I'm simply supplying the full path name to the new binary in the script. I have some other systems using the old openocd and need to check them before doing anything drastic.
 

Offline damacloid

  • Newbie
  • Posts: 1
  • Country: pk
Re: Qmtech Artix 7 Wukong board
« Reply #43 on: December 25, 2021, 12:08:02 am »
Hey there, Sorry for not adding to the conversation and asking unuseful questions in general but here it goes.
I am looking to get this board as my first and hope to use it for exploring modern computer stack from first principles. I want to play around with computer architectures, processors. Maybe implement a RISC-5 soft processor, customize its instructions etc.
After reading a bit, I've found that Xilinx Artix-7 100t has internal USB-JTAG circuitry which I presume doesn't need an external programmer like Xilinx Platform Cable USB II to configure/program and can be configured directly via PC to USB connection. Looking at QMTech github documentation files, it seems like I do need an external programmer. So I am a bit confused and the question is
1. Do I need an external programmer?
2. Does it have to be Xilinx Platform Cable USB II or the older Platform cable USB will also work? Sorry for being dumb.
Also, did you face any stability issues caused by the undersized decoupling and power supplies?
« Last Edit: December 25, 2021, 12:09:40 am by damacloid »
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #44 on: January 02, 2022, 11:31:18 am »
Not sure if the external programmer is needed, but that's the only thing I ever used - there doesn't seem to be any other wat. I have a 'compatible' cable that I got cheaply from Amazon.
 

Offline colorfred

  • Newbie
  • Posts: 2
  • Country: de
Re: Qmtech Artix 7 Wukong board
« Reply #45 on: January 12, 2022, 01:30:27 pm »
I have this board and im using the same board files.

The issue i found so far - somehow the AXI Quad SPI does not work, within a SREC bootloader.
 

Offline colorfred

  • Newbie
  • Posts: 2
  • Country: de
Re: Qmtech Artix 7 Wukong board
« Reply #46 on: January 12, 2022, 01:34:52 pm »
For Xilinx Vivado, i think it must be a Xilinx compatible JTAG programmer. Im using a chinese clone, you can buy it at Amazon.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Qmtech Artix 7 Wukong board
« Reply #47 on: January 12, 2022, 07:52:18 pm »
After reading a bit, I've found that Xilinx Artix-7 100t has internal USB-JTAG circuitry which I presume doesn't need an external programmer like Xilinx Platform Cable USB II to configure/program and can be configured directly via PC to USB connection.

That is not true. The chip has no such interface.

Quote
Looking at QMTech github documentation files, it seems like I do need an external programmer. So I am a bit confused and the question is
1. Do I need an external programmer?
2. Does it have to be Xilinx Platform Cable USB II or the older Platform cable USB will also work? Sorry for being dumb.

if the board does not have an on-board Platform Cable USB II (or compatible, to be recognized by the Xilinx tools) then you will need one. Surely the documentation is clear on that?
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 225
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #48 on: January 14, 2022, 02:23:01 pm »
Digilent has some low cost programmer recognized by vivado.
Note that you may need an adapter for the QMtech board or flying wires.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #49 on: January 14, 2022, 06:01:28 pm »
Yes, all QMTECH boards (at least that I've seen) have a 6-pin header for JTAG access, and it's pin-compatible with the Digilent HS2/HS3 adapters, so you can plug that in directly without requiring flying wires, IIRC.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf