Qmtech Artix 7 Wukong board - Page 1
Forum section: electronics / general

author: djrm
author_rank: Contributor
timestamp: July 31, 2021, 11:12:22 pm
content: 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_Boardhth David.

author: radiolistener
author_rank: Super Contributor
timestamp: August 01, 2021, 08:34:14 am
content: 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.

author: djrm
author_rank: Contributor
timestamp: August 01, 2021, 09:24:36 am
content: Quote from: radiolistener on August 01, 2021, 08:34:14 amHi 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 01, 2021, 07:39:56 pm
content: 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.

author: djrm
author_rank: Contributor
timestamp: August 01, 2021, 09:17:48 pm
content: Quote from: SiliconWizard on August 01, 2021, 07:39:56 pmGreetings 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.

author: Mario87
author_rank: Frequent Contributor
timestamp: August 02, 2021, 09:20:25 am
content: 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-profileThey 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=552However 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 02, 2021, 04:43:41 pm
content: Quote from: djrm on August 01, 2021, 09:17:48 pmYou 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?

author: djrm
author_rank: Contributor
timestamp: August 02, 2021, 08:58:02 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 02, 2021, 10:38:05 pm
content: 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%?

author: ebclr
author_rank: Super Contributor
timestamp: August 03, 2021, 11:51:43 am
content: It's not that hard to add a heat sink if necessary

author: asmi
author_rank: Super Contributor
timestamp: August 03, 2021, 01:35:32 pm
content: Quote from: ebclr on August 03, 2021, 11:51:43 amIt'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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 03, 2021, 02:26:44 pm
content: I have one of those; makes for an excellentLitexdev 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 withDolu1990's USB Pmod.I just wish they had a version with more memory. 256 MiB is short for a quad-core SoC.

author: djrm
author_rank: Contributor
timestamp: August 03, 2021, 02:41:27 pm
content: 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 03, 2021, 04:33:20 pm
content: Quote from: djrm on August 03, 2021, 02:41:27 pmWith 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...)

author: djrm
author_rank: Contributor
timestamp: August 03, 2021, 04:58:56 pm
content: Quote from: dolbeau on August 03, 2021, 04:33:20 pmI'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.

author: djrm
author_rank: Contributor
timestamp: August 04, 2021, 09:52:12 pm
content: 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 295 times.)

author: djrm
author_rank: Contributor
timestamp: August 06, 2021, 08:53:12 pm
content: Quote from: dolbeau on August 03, 2021, 02:26:44 pmI 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.

author: djrm
author_rank: Contributor
timestamp: August 06, 2021, 09:50:40 pm
content: 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 07, 2021, 06:38:27 am
content: Quote from: djrm on August 06, 2021, 09:50:40 pmWeird, 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 inthis repository (100T only, the one I have)andthis repository (100T or 200T, and the files are called V02...).If there's enough commonality you might create a variant of the previous board inLitex-Boards, but if some pins were reassigned you might be better off with a new platform.

author: djrm
author_rank: Contributor
timestamp: August 07, 2021, 09:42:30 pm
content: Quote from: dolbeau on August 07, 2021, 06:38:27 amThe 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 08, 2021, 07:43:36 am
content: Quote from: djrm on August 07, 2021, 09:42:30 pmDo 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:CONFIG_INPUT_EVDEV, CONFIG_INPUT_MOUSEDEV, CONFIG_KEYBOARD_ATKBD, ...), and then to switch the console from the serial port to the framebuffer (e.g. removeCode:console=liteuartand addCode:fbcon=map:0to the liunx options)

author: djrm
author_rank: Contributor
timestamp: August 08, 2021, 09:12:22 am
content: Quote from: dolbeau on August 08, 2021, 07:43:36 amAh, 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 08, 2021, 09:21:49 am
content: Quote from: djrm on August 08, 2021, 09:12:22 amI havea 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.

author: djrm
author_rank: Contributor
timestamp: August 08, 2021, 09:50:05 am
content: Quote from: dolbeau on August 08, 2021, 09:21:49 amVery 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

author: djrm
author_rank: Contributor
timestamp: August 08, 2021, 10:34:29 am
content: Quote from: djrm on August 08, 2021, 09:50:05 amsmall 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 08, 2021, 12:03:47 pm
content: Quote from: djrm on August 08, 2021, 10:34:29 amThe 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 :-(

author: djrm
author_rank: Contributor
timestamp: August 08, 2021, 06:44:08 pm
content: 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.

author: BrianHG
author_rank: Super Contributor
timestamp: August 08, 2021, 07:52:56 pm
content: Ahh, the good all Little-Endian - Big-Endian pixel packing/addressing problem...

author: djrm
author_rank: Contributor
timestamp: August 08, 2021, 10:35:28 pm
content: Quote from: BrianHG on August 08, 2021, 07:52:56 pmAll 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.

author: BrianHG
author_rank: Super Contributor
timestamp: August 08, 2021, 10:42:51 pm
content: 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.

author: djrm
author_rank: Contributor
timestamp: August 08, 2021, 10:57:38 pm
content: Quote from: BrianHG on August 08, 2021, 10:42:51 pmI took a photo at the time, I think it was simply red and blue swapped in this instance.Very cold looking penguins.

author: BrianHG
author_rank: Super Contributor
timestamp: August 08, 2021, 11:13:03 pm
content: 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 09, 2021, 06:09:12 am
content: Quote from: djrm on August 08, 2021, 06:44:08 pmNever 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).

author: djrm
author_rank: Contributor
timestamp: August 09, 2021, 06:37:23 am
content: Quote from: dolbeau on August 09, 2021, 06:09:12 amLitex was installed following the instructions here:https://github.com/enjoy-digital/litex/wiki/InstallationLinux was installed by following the instructions here:https://github.com/litex-hub/linux-on-litex-vexriscvI dont know the answers to your memory question.I have changed the supplied qmtech_wukong configuration files and saved them as qmtech_wukong_02The 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 09, 2021, 09:02:52 am
content: Quote from: djrm on August 09, 2021, 06:37:23 amIt's likely to be wishbone instead of native, as IIRC you cannot have L2 cache and native litedram - and your log says:Code:CPU:VexRiscv SMP-LINUX @ 100MHzBUS:WISHBONE 32-bit @ 4GiBCSR:32-bit dataROM:64KiBSRAM:8KiBL2:2KiBSDRAM: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 SRAMapparently I have the SRAM as well, never noticed it!). Mine look like this:Code:class Qmtech_WuKong(Board):SPIFLASH_PAGE_SIZE = 256SPIFLASH_SECTOR_SIZE = 64*kBSPIFLASH_DUMMY_CYCLES = 11soc_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_wukongBoard.__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 likeCode:--l2-size 0 --integrated-sram-size 0It's still a little bit bleeding-edge...

author: djrm
author_rank: Contributor
timestamp: August 09, 2021, 10:40:40 am
content: Quote from: dolbeau on August 09, 2021, 09:02:52 amWith linux configured as below (with L2 cache removed) the boot logo appears properly.Code:class Qmtech_WuKong_02(Board):SPIFLASH_PAGE_SIZE = 256SPIFLASH_SECTOR_SIZE = 64*kBSPIFLASH_DUMMY_CYCLES = 11soc_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_02Board.__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 159 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 09, 2021, 12:51:27 pm
content: Quote from: djrm on August 09, 2021, 10:40:40 amGot 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.

author: djrm
author_rank: Contributor
timestamp: August 11, 2021, 11:21:43 pm
content: 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.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 12, 2021, 10:33:05 am
content: 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 onhttps://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.

author: djrm
author_rank: Contributor
timestamp: August 12, 2021, 11:03:11 am
content: Quote from: dolbeau on August 12, 2021, 10:33:05 amNot 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.

author: djrm
author_rank: Contributor
timestamp: August 12, 2021, 04:28:45 pm
content: 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:# 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 ftdiftdi vid_pid 0x0403 0x6014ftdi channel 0ftdi layout_init 0x00e8 0x60ebreset_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.cfgadapter speed 25000initjtagspi_init 0 bscan_spi_xc7a100t.bitjtagspi_program /opt/Litex/litex-boards/litex_boards/targets/build/qmtech_wukong_02/gateware/qmtech_wukong_02.bin 0#xc7_program xc7.tapexitDoes 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:david@I7MINT:/opt/Litex/litex-boards/litex_boards/targets$ /opt/Litex/openocd/src/openocd -f openocd_xc7_ft232_new.cfgOpen On-Chip Debugger 0.11.0+dev-00294-g3d9534b8a-dirty (2021-08-12-16:54)Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlInfo : 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 kHzInfo : 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 msInfo : sector 1 took 261 msInfo : sector 2 took 249 msInfo : sector 3 took 245 msInfo : sector 4 took 281 msInfo : sector 5 took 273 msInfo : sector 6 took 263 msInfo : sector 7 took 256 msInfo : sector 8 took 266 msInfo : sector 9 took 265 msInfo : sector 10 took 252 msInfo : sector 11 took 258 msInfo : sector 12 took 249 msInfo : sector 13 took 253 msInfo : sector 14 took 257 msInfo : sector 15 took 245 msInfo : sector 16 took 250 msInfo : sector 17 took 247 msInfo : sector 18 took 248 msInfo : sector 19 took 235 msInfo : sector 20 took 257 msInfo : sector 21 took 252 msInfo : sector 22 took 258 msInfo : sector 23 took 240 msInfo : sector 24 took 256 msInfo : sector 25 took 256 msInfo : sector 26 took 255 msInfo : sector 27 took 247 msInfo : sector 28 took 265 msInfo : sector 29 took 251 msInfo : sector 30 took 243 msInfo : sector 31 took 251 msInfo : sector 32 took 257 msInfo : sector 33 took 257 msInfo : sector 34 took 259 msInfo : sector 35 took 249 msInfo : sector 36 took 260 msInfo : sector 37 took 263 msInfo : sector 38 took 252 msInfo : sector 39 took 250 msInfo : sector 40 took 266 msInfo : sector 41 took 257 msInfo : sector 42 took 260 msInfo : sector 43 took 247 msInfo : sector 44 took 229 msInfo : sector 45 took 242 msInfo : sector 46 took 244 msInfo : sector 47 took 238 msInfo : sector 48 took 252 msInfo : sector 49 took 260 msInfo : sector 50 took 243 msInfo : sector 51 took 237 msInfo : sector 52 took 260 msInfo : sector 53 took 249 msInfo : sector 54 took 259 msInfo : sector 55 took 259 msInfo : sector 56 took 267 msInfo : sector 57 took 262 msInfo : sector 58 took 268 msInfo : Found flash device 'cyp s25fl128l' (ID 0x00186001)david@I7MINT:/opt/Litex/litex-boards/litex_boards/targets$

author: dolbeau
author_rank: Regular Contributor
timestamp: August 12, 2021, 04:33:27 pm
content: 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).

author: djrm
author_rank: Contributor
timestamp: August 13, 2021, 12:14:33 pm
content: Quote from: dolbeau on August 12, 2021, 04:33:27 pmThe 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.

author: damacloid
author_rank: Newbie
timestamp: December 25, 2021, 12:08:02 am
content: 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 is1. 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?

author: dolbeau
author_rank: Regular Contributor
timestamp: January 02, 2022, 11:31:18 am
content: 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.

author: colorfred
author_rank: Newbie
timestamp: January 12, 2022, 01:30:27 pm
content: 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.

author: colorfred
author_rank: Newbie
timestamp: January 12, 2022, 01:34:52 pm
content: For Xilinx Vivado, i think it must be a Xilinx compatible JTAG programmer. Im using a chinese clone, you can buy it at Amazon.

author: Bassman59
author_rank: Super Contributor
timestamp: January 12, 2022, 07:52:18 pm
content: Quote from: damacloid on December 25, 2021, 12:08:02 amThat is not true. The chip has no such interface.Quoteif 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?

author: mac.6
author_rank: Regular Contributor
timestamp: January 14, 2022, 02:23:01 pm
content: Digilent has some low cost programmer recognized by vivado.Note that you may need an adapter for the QMtech board or flying wires.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 14, 2022, 06:01:28 pm
content: 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.

author: mac.6
author_rank: Regular Contributor
timestamp: January 17, 2022, 09:07:11 am
content: 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.