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

0 Members and 1 Guest are viewing this topic.

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Qmtech Artix 7 Wukong board
« on: July 31, 2021, 11:12:22 pm »
Greetings everyone,

This is my first post although I have been a member for a while now. I have one of the Qmtech Wukong boards and whilst learning about it I have been creating a git repo containing some support files. of interest may be the board definition files, ddr3 memory and gigabit ethernet components I have been experimenting with. Everything is briefly described here with links to the files in the readme. Its mainly Verilog and built with Vivado, I'll be adding accompanying Vitis projects shortly.

I would be interested to hear from anybody who has used one of these boards.

https://github.com/DavidJRichards/QMTECH_XC7A100T_Wukong_Board

hth David.
 
The following users thanked this post: FlyingDutch

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 3227
  • Country: ua
Re: Qmtech Artix 7 Wukong board
« Reply #1 on: August 01, 2021, 08:34:14 am »
Don't know about Xilinx boards from QMTECH, but Altera boards have some issues. For example GMII PHY clock signals are connected to a usual GPIO pins (not CLK), which prevents to use it to clock PLL for clock generation. Also they don't have CLK inputs, the only CLK input which is used is onboard 50 MHz osclillator, so you will be unable to clock your design from any other source, because Altera PLL can be clocked from CLK pins only.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #2 on: August 01, 2021, 09:24:36 am »
Don't know about Xilinx boards from QMTECH, but Altera boards have some issues. For example GMII PHY clock signals are connected to a usual GPIO pins (not CLK), which prevents to use it to clock PLL for clock generation. Also they don't have CLK inputs, the only CLK input which is used is onboard 50 MHz osclillator, so you will be unable to clock your design from any other source, because Altera PLL can be clocked from CLK pins only.

Hi radiolistner,

Thanks, I'll have to check which pins are clock inputs, do you have a link/model for the Altera board with this problem, I'd like to compare the schematic with my own board.
I have a problem already with the qspi flash where I can't synthesize the design with the pin it is using for its clock. I have yet to test any IP using the qspi. Vitis is able to write to it though. I am looking for a PL design example to test the qspi flash.

Kind regards, David.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #3 on: August 01, 2021, 07:39:56 pm »
I have used a few QMTECH boards with XIlinx parts, but not this one. They are OK for prototyping stuff, but all my boards have "smaller" FPGAs.

What I've read about those boards with Artix 7 100T/200T is that decoupling, and power supplies, are undersized. Not too mention no heatsink. So forget about using them using a significant fraction of the internal resources at high frequencies.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #4 on: August 01, 2021, 09:17:48 pm »
I have used a few QMTECH boards with XIlinx parts, but not this one. They are OK for prototyping stuff, but all my boards have "smaller" FPGAs.
What I've read about those boards with Artix 7 100T/200T is that decoupling, and power supplies, are undersized. Not too mention no heatsink. So forget about using them using a significant fraction of the internal resources at high frequencies.

Greetings SiliconWizard, thanks for your comments.

I do not know what you have read about these boards but I see no sign of any heat sinks on any of the other entry level development boards from the major manufacturers. For my purpose which is learning about these devices the board appears quite suitable, especially considering the cost compared to the alternatives.

I shall probably find out if the decoupling is insufficient but I haven't had any stability or heat problems - I like to leave it running for a day or two from time to time to check from time to time. I imagine extra decoupling cant be retro fitted in a meaningful way.

Some other Altera boards I have bought have had loads of small peripherals onboard, eventually these become a hinderance taking up valuable pins which are more usefully exposed for other purposes, I like the mix on this board with just the high speed components on board together with a big expansion port.

Kind regards, David.
 

Offline Mario87

  • Regular Contributor
  • *
  • Posts: 247
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #5 on: August 02, 2021, 09:20:25 am »
Looks interesting, but from the picture on your GitHub it seems that the traces to the HDMI and GTP headers are not length matched for the differential pairs, so that might start causing issues on higher speed projects and kind of makes the GTP transceivers no more useful than the standard IO which are still rated for 950Mbps on the -1 speed rated devices (which I assume this is) or 1250Mbps on the higher speed rated 7-series FPGA's (these speeds are specifically for LVDS networking applications according to the Xilinx datasheets).

I do know what you mean about most dev boards having IO used up by other peripherals and it can be a pain. However Trenz Electronic make some small SoM's with various FPGA's such as this one... https://shop.trenz-electronic.de/en/TE0712-02-82C36-L-FPGA-Module-with-Xilinx-Artix-7-XC7A200T-2C-1-GByte-DDR3-4-x-5-cm-low-profile

They use Razor Beam High-Speed hermaphroditic Terminals and also sell what they call "carrier boards" like this if you want something pre-made like most development boards... https://shop.trenz-electronic.de/en/TE0701-06-Carrier-Board-for-Trenz-Electronic-4-x-5-Modules?c=552

However the great thing is because it is an SoM you can just make your own carrier board and have all IO connected as you want, or your carrier board can be nothing but header pins if thats what you desire in order to give full flexibility.

Yes, they are on the more expensive side and yes making your own custom barrier board is not something everyone can do with ease and yes it is more work / effort, but if you want true flexibility and a system that has been designed with all the correct characteristics from a "reputable" company then it seems the best option from what I have seen so far.

I actually nearly got one, but in the end opted for a more traditional dev board from Digilent purely because for me to make use of their SOM in development stages at least, I would need to make up my own custom carrier board to suit my needs which is not out of the realms of possibility, but that in itself is not exactly a small task (as I mentioned above) as I have to consider all the power rails, impedance, manufacturing of the board, how to program and interface to the FPGA via Vivado, etc, etc. A lot less hassle to just make use of an "off the shelf" board for my needs, but just wanted to put it out there that there are high end boards from the main manufacturers that will give great flexibility providing you have the time to spend getting everything as you want.
« Last Edit: August 02, 2021, 09:22:40 am by Mario87 »
 
The following users thanked this post: paf

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #6 on: August 02, 2021, 04:43:41 pm »
I do not know what you have read about these boards but I see no sign of any heat sinks on any of the other entry level development boards from the major manufacturers. For my purpose which is learning about these devices the board appears quite suitable, especially considering the cost compared to the alternatives.

You probably missed the point, then. The board you showed sports Artix-7/100T or 200T, which are already BIG FPGAs. Most "entry-level" boards out there with Artix-7 parts only sport an Artix-7/35T or so.

One example of board from Digilent with a 100T is this one: https://store.digilentinc.com/usb104-a7-artix-7-fpga-development-board-with-syzygy-compatible-expansion/
I wouldn't call it "entry level". That said, it doesn't seem to come with a heatsink. But I would seriously consider adding one if I were going to do anything "serious" with this board.

Point is, 100T (and all the more 200T) can dissipate A LOT of power, and a simple review of the schematics (that QMTECH kindly provides) shows that power supplies are undersized if you want to use the FPGA at its full potential. It can also be seen that decoupling is a bit on the low side.

As to heat dissipation, even a 35T will get pretty hot while running depending on your design, but a heatsink is usually not required. A 100T or 200T? Things will get hairy. That said, you can always add a heatsink on the FPGA yourself. The onboard power supplies are more problematic.

Anyway, unless you really need some FPGA this big (I don't know what you want to do), I'd highly suggest going for a more modest Artix7-35T. Those will dissipate a lot less power, and for those, QMTECH boards are usually adequate. But maybe, just maybe, you're interested in this board not for the "large" FPGA itself, but for all the connectors?
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #7 on: August 02, 2021, 08:58:02 pm »
Hi SiliconWizard,

Thanks for the detailed answer, it is much appreciated. All points taken onboard.
I can see now why I maybe should have got a mainstream board, I'm learning a lot one way or another.

My main reason for getting this board was larger size and easy arrangement of many expansion pins. I'm not too worried about the speed although I have bought it as an upgrade to another part. I have a heatsink I can fit if I find it is getting hot but so far it is only running cool.

I am hoping to use it for some retro computing simulations. Hopefully with HDMI output and using the ddr3 ram for a framebuffer.
Kind regards, David.

 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #8 on: August 02, 2021, 10:38:05 pm »
If you're only running modest designs on it at relatively low frequencies, I don't think you'd really have much to worry about.
I was warning you because people buying a board with a XC7/100T or 200T would often expect to be able to use them at their "full potential", and for this, those boards will likely not cut it.
Retro computing stuff usually does not take that many FPGA resources. The benefit of a 100T or 200T would be the large internal block RAM that you can use as general purpose RAM, but in terms of LUTs, I doubt you'll get anywhere close to even 50%?
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: Qmtech Artix 7 Wukong board
« Reply #9 on: August 03, 2021, 11:51:43 am »
It's not that hard to add a heat sink if necessary
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: Qmtech Artix 7 Wukong board
« Reply #10 on: August 03, 2021, 01:35:32 pm »
It's not that hard to add a heat sink if necessary
It's not, but you've got to know that you have to do it, because unlike CPUs, FPGAs don't have built-in thermal protection and will happily fry themselves before user realized what's going on.

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #11 on: August 03, 2021, 02:26:44 pm »
I have one of those; makes for an excellent Litex dev board - cheap and plenty of space in the FPGA.

I just added a micro-sd card pmod for the Linux boot/root.

I did not have issue with the memory or Ethernet (I run Ethernet on a 100 Mbps switch, as the SoC was a bit slow to keep up with a full 1 Gbps link), and even successfully used the HDMI port  (but only tried 800x600 and maybe 1024x768).

It also worked fine with Dolu1990's USB Pmod.

I just wish they had a version with more memory. 256 MiB is short for a quad-core SoC.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #12 on: August 03, 2021, 02:41:27 pm »
Thanks for the heads up regarding Litex, I'm very interested to see a nice set or ready made general purpose ip for this and other boards too. I shall try LItex when I think of an application for it, maybe make it into a nice vintage style graphics terminal.
One of the reasons for switching from my previous board was because I could not connect anything to its USB pins, I did manage to get a serial USB IP working but host is what I really wanted so I'll be looking into the USB pmod with interest too.
Kind regards, David.
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #13 on: August 03, 2021, 04:33:20 pm »
Thanks for the heads up regarding Litex, I'm very interested to see a nice set or ready made general purpose ip for this and other boards too.

With linux-on-litex-vexriscv, you should be able to get a working Linux (using Busybox) for a SMP RV32 SoC using the VexRiscv cores fairly quickly, including support for Ethernet, micro-sd (standard Pmod can be used, as there's no micro-sd in the Qmtech Wukong), and the onboard DDR3. However, no keyboard or mouse by default - I created a prototype PS/2 controller for a PS/2 Pmod (along with a linux driver), but I gave up on it when I got the USB Pmod. However if you want one of those you'll need to manufacture yourself, it's not in production that I know of...

Also beware while you can run X11 in there (and even Doom!), it's a dumb framebuffer so not very fast. Though for a terminal emulator it would probably be fine (but so would be much cheaper/easier solutions like a Pi...)
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #14 on: August 03, 2021, 04:58:56 pm »
Also beware while you can run X11 in there (and even Doom!), it's a dumb framebuffer so not very fast. Though for a terminal emulator it would probably be fine (but so would be much cheaper/easier solutions like a Pi...)

I'm not looking for high speed, as you say there are much easier ways to achieve that. I have some diy pmod type interfaces including PS/2 keyboard and MIcroSD so it should be straightforward (he said!) I haven't studied the USB yet. I did see a USB phy on ebay a while back (microchip USB3300), perhaps it would help to keep the wiring simple.

I'll have a go at installing the Litex toolchain shortly.
Kind regards, David.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #15 on: August 04, 2021, 09:52:12 pm »
Anyone with a board like this may be interested in these protective top and bottom boards.
They are laser cut from 3mm acrylic.
The openSCAD source includes 3D and 2D representations.
I exported the 2D as DXF and then into Corel laser to cut them.
The picture shows one of the paper templates I cut for checking the fit.
There is a hole for a heatsink, the rubber feet stock to the bottom of the board will need to be removed.
hth David.
* WukongBaseboard-scad.txt (2.64 kB - downloaded 253 times.)
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #16 on: August 06, 2021, 08:53:12 pm »
I have one of those; makes for an excellent Litex dev board - cheap and plenty of space in the FPGA.

I have found that the default Litex configuration does not work without changing the pin settings in boards/platforms/qmtech_wukong.py to suit the later version 1.0 board I have.
In particular the clock and leds need changing, don't know how to enable ethernet and video console yet...
Otherwise it seems to have just worked strait out of the box.
Kind regards David.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #17 on: August 06, 2021, 09:50:40 pm »
One more thing, unlike the earlier version of the board the V1.0 has a micro SD card socket.
I only noticed this difference today, none of the examples mention it and its hidden under the board.
I'm looking at how to amend the platform definition to include this.
hth David.
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #18 on: August 07, 2021, 06:38:27 am »
One more thing, unlike the earlier version of the board the V1.0 has a micro SD card socket.
I only noticed this difference today, none of the examples mention it and its hidden under the board.
I'm looking at how to amend the platform definition to include this.

Weird, mine definitely hasn't got anything underneath, yet checking on AliExpress the pictures now have one.

It seems the name has been kept but the design has changed from what is in this repository (100T only, the one I have) and this repository (100T or 200T, and the files are called V02...).

If there's enough commonality you might create a variant of the previous board in Litex-Boards, but if some pins were reassigned you might be better off with a new platform.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #19 on: August 07, 2021, 09:42:30 pm »
If there's enough commonality you might create a variant of the previous board in Litex-Boards, but if some pins were reassigned you might be better off with a new platform.

The board is mostly the same but I think a build switch or new platform and target will be the cleanest option, having said that I've simply edited the existing files to get started.

Could you explain how the ps/2 keyboard is enabled for the hdmi console please? there are only two examples I can find with ps/2 keyboards and no obvious way to enable it. any pointers gratefully received. I seem to have hdmi ethernet tftp and sdcard working but have not managed to build anything to test them with yet.

I have updated my Wukong readme.md with the small changes I have made to build LItex for this board..

Kind regards, David.
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #20 on: August 08, 2021, 07:43:36 am »
Could you explain how the ps/2 keyboard is enabled for the hdmi console please? there are only two examples I can find with ps/2 keyboards and no obvious way to enable it. any pointers gratefully received. I seem to have hdmi ethernet tftp and sdcard working but have not managed to build anything to test them with yet.

Do you mean in the gateware or in the Linux buildroot distribution ?

For the gateware, Litex does not have a PS/2 controller - or in fact any 'standard' way of enabling a keyboard except the USB Host.

For buildroot (if you have found a way of enabling a keyboard in the gateware), you need first to enable the devices in the kernel configuration (e.g.
Code: [Select]
CONFIG_INPUT_EVDEV, CONFIG_INPUT_MOUSEDEV, CONFIG_KEYBOARD_ATKBD, ...), and then to switch the console from the serial port to the framebuffer (e.g. remove
Code: [Select]
console=liteuart and add
Code: [Select]
fbcon=map:0 to the liunx options)
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #21 on: August 08, 2021, 09:12:22 am »
For the gateware, Litex does not have a PS/2 controller - or in fact any 'standard' way of enabling a keyboard except the USB Host.

Ah, sorry I misunderstood, I see from your earlier post you are not using a PS/2 keyboard. Time to get soldering up a USB pmod.
I had assumed that the video console would have a seperate keyboard, it seems no.

Thanks, David.
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #22 on: August 08, 2021, 09:21:49 am »
Ah, sorry I misunderstood, I see from your earlier post you are not using a PS/2 keyboard.

I have a draft PS/2 controller and the associated linux driver, but it's very rough.
It still might be quicker/cheaper than building a USB Pmod.

I'm planning to try it with a mouse as well (using a splitter cable), but I haven't had the time yet.
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #23 on: August 08, 2021, 09:50:05 am »
I have a draft PS/2 controller and the associated linux driver, but it's very rough.
It still might be quicker/cheaper than building a USB Pmod.
Very interesting, That is just what I was looking for.

I have a working PS/2 keyboard on my Petalinux Zynq board based on this project. http://www.deater.net/weave/vmwprod/hardware/pi-ps2/ There is a matching linux device driver.
D
 

Offline djrmTopic starter

  • Contributor
  • Posts: 41
  • Country: gb
Re: Qmtech Artix 7 Wukong board
« Reply #24 on: August 08, 2021, 10:34:29 am »
I have a draft PS/2 controller and the associated linux driver, but it's very rough.
Very interesting, That is just what I was looking for.

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?

tia, David.
 

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.
 

Offline 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.
 

Offline 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.
 

Offline 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.
 

Offline 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.
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 225
  • Country: fr
Re: Qmtech Artix 7 Wukong board
« Reply #50 on: January 17, 2022, 09:07:11 am »
HS3 do not have 6 pins connection, only 2x7 2mm pitch, HS2 has both.
The QMtech board I have use the 1x6pins 2.54mm that HS2 provides.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf