Micropython and Arty S7 support #9
Comments
|
It looks like something is going wrong with JTAG programming |
|
Yes, you are right, I haven't use before openocd with Xilinx on my linux box. So I am not sure if it fails because of JTAG hardware issue or is something more related to bad configuration of the top.bit, which actually build correctly, but since my board is S7 and not A7... Do you know how can I program it using Vivado? |
|
You can't program a Arty A7 bitstream onto a Arty S7. They are not the same device. |
|
@cr1901 is working on adding support for the Arty S7 to the LiteX-buildenv which Fupy uses. Once that support is working, then Fupy should just work too. |
|
Yes you are certainly right, Could you please let me know which files should I look to change for make this project available for S7? I suspect one is ./platforms/arty.py, but if you can give me some details so I can go after them quickly I will appreciate you. |
|
@cr1901 can give you more information. The primary thing which needs to work is the DDR memory on the board. Once that works, everything else should be pretty easy. |
|
@mithro As far as I understand both boards have same DDR3 memory P/N MT41K128M16JT-125 . Perhaps the problem I am seeing is more related to Quad-SPI memory since it fails in the very first stage of openocd load. Actually Arty-A7 has Micron part number N25Q128A13ESF40, and Arty S7 has Spansion part number S25FL128S. I found that Quad-SPI is defined in arty.py file as below Actually Xilinx pn should change too. I just don't want to start changing things without a better understanding of all scripts involved. Please if possible @cr1901 will appreciate your knowledge. |
|
I will take a look early next week. Quad SPI flashing works on my end, but I also need to push some changes to openocd since it doesn't understand Spartan7 yet. |
|
@mhanuel26 Sorry I forgot to update this thread. Basic Arty S7 functionality works, but I'm not prepared to merge it just yet (still haven't tested the DDR3). Re: the JTAG errors, they are ignorable... OpenOCD doesn't expect Spartan 7 part numbers, and so treats them as errors, but the actual programming works fine. I submitted a patch for Spartan 7 part numbers. I also intend to to submit arty-s7 config files upstream once this patch is accepted. In the meantime, use the following instructions until everything's merged into master:
Once you've done these steps, openocd programming should just work.
|
|
@cr1901 I follow your intructions but I think I am missing something I update the litex under thirparty Then I create the openocd files and .litex directory with .bit files on it. I am not sure of I need only the JTAG upload or the writing to flash, trying the JTAG upload give me the same errors as before, which I am not sure those are the ones you said to ignore. I have try the command using openocd directly as above and also by doing it with make gateware-load which uses
with same results, the above digilent_arty.cfg do the same as your two openocd files I guess I haven't try the writing to flash since I am not sure which values should have $flash_addr and $upload_file, I understand the $proxy should be bscan_spi_xc7s50.bit Would you kindly please let me know where is my error? |
|
Okay, let's focus on this one at a time.
You can ignore all errors of the form: Depsite the fact they say This tells me your command succeeded :).
I believe they are the same file; I instructed you to create a separate file just in case we have to change the That being said, I should probably commit both patches to @mithro's conda repo until my patch(es) gets accepted; openocd is... slow at receiving patches.
|
|
@cr1901 Thank you very much for your support, Now I can upload the .bin using the second option to write to flash but the firmware-load hangs After that I have tried to reset the board, also unplug, I know the .bin is programmed since the demo has gone, but when I do make firmware-load, at the end I got the following which don't finish. I have tried the same taken off the CR_RST jumper with same results. Is the make gateware ok with documentation here, i.e. PLATFORM=arty, since your litex has include a new arty_s7.py platform file? How can I debug this further? Will appreciate your comments. |
|
Hi @cr1901 , I did all the steps as suggested and bitstream loads now, but I cannot load the FuPy firmware. Could you please let me know what am I missing here? Thank you in advance, |
|
@mhanuel26 I do not know what is wrong and have not had the opportunity to check. It looks like a Makefile bug tho. I don't see an error reason however. I've had issues w/ loading firmware images on my end as well (the Makefile expects to load an |
|
@cr1901, thank you for letting me know, I thought it was only me. |
|
@cr1901 @mithro I have successfully run micropython firmware on Arty S7, at least a hello world This is what I did. I recompile using PLATFORM=arty doing some changes to original arty files, I know it should be a new platform such arty_s7, but that might be better specified by you I guess. First I took your arty s7 platform file and replace your original file with this modifications. The clk100 have some conflict with VCCOs, this was the error
I remove the ethernet definition for 25 MHz clock in targets/base.py file since Arty S7 don't need it and complain with your file. I add this missing part in your Platform class ` # From https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf The sector size of this memory is also 64K, the only thing that makes me doubt is that it has an hybrid sector scheme, there are 32 4k sectors, more info on page 44 here After this I load bitstream as
then make firmware-load do the job as shown above. Just one question, to create a new target it just suffice to create i.e. the arty_s7 folder with base.py on it and also the platform file arty_s7.py and change PLATFORM=arty_s7 ? |
Yes, that is sufficient, but please don't do that. First off, I'm surprised the DDR controller worked from Arty A7 on Arty S7 without changes. Second, I'm concerned about this error: This means I got something wrong in the platform file for the DDR RAM that I need to check before I commit. Your change worked, but I think it would stop working for more complex designs; you're using an I/O standard meant for differential I/O to drive the system clock! |
|
Well, I did the change after looking at the schematic, if you look for the Arty A7 you will find clock is LVCMOS33 And my Rev b of Arty S7 is The upper rail is actually 1.35 volts. It's not like I can test too much right now as the default micropython compile but I tried testing the leds using it should turn on LED2 but it does nothing, same for other numbers. Do you know how to add standard libraries such time to litex micropython? |
|
Sorry I click close by accident while posting a replay... @cr1901 When you said
Shouldn't be that the case if both DDR3 memory are same P/N MT41K128M16JT-125 and looking at the datasheet the configuration seems the same? |
|
@mhanuel26 You are 100% correct re: the clock, I apologize. And... that is weird to me, but yes that is a bug w/ my code and I'll fix it, tyvm! I sadly don't know how to add such libraries to micropython :(. I'm working on finalizing the arty_s7 platform this morning. |
|
I am happy to contribute, I understand you said about the led that is a bug right? Ok I will wait for your changes, could you please kindly let me know whenever you do the commit. Thanks for everything. |
I'm not sure what's going on with the LEDs. After I finalize arty_s7, could you go ahead and push your changes to Github (including Btw, out of curiosity, how'd you fix this error described above? |
|
Ok I commit to my fork what I have, just because you ask remember I use the Arty files instead of creating new ones. After you do the changes, I first do Then I don't do make gateware-load since that seems to do nothing, instead I manually load it using your version of openocd command
That ends up with something like Thereafter I load micropython as
Notice that after bitstream is loaded only the red PWR led is on. Verify after you connect the board, for some reason I really don't understand, the Digilent Adept rules was breaking things, for example when it was causing problems dmesg output was As you can see ttyUSB1 was disconnecting during the process. This might or not be your case but I comment file /etc/udev/rules.d/52-digilent-usb.rules After that reload udev rules (i.e. debian)
dmesg | tail in my working board is Hope this helps. |
|
Okay this looks like a Linux issue; I'm on Windows, sadly :(. So a few other things I forgot to mention:
I wasn't sure that the bitslip/delay constants would be the same between both boards, but I did a test, and bitslip of 3, and delay of 14 works fine for both boards (
These are all |
|
@cr1901 Thank you for the comments, At the end you solve the issue on your windows machine? Did you figure out what might be the LED problem? |
|
Ok, just found the LED problem and with some changes LEDs works now. I did the following changes manually on the code, not sure if it's the correct way to fix them, since that for sure would break micropython. Under third_party/micropython/litex_leds.c original code is but after looking at my generated folder and trying to locate the CSR_CAS_BASE definition, I end up thinking that something mess up, the functions defined in csr.h are called leds_out_read and leds_out_write , that is without the starting cas_. After changing those references my Arty_S7 leds works. What would be the correct way to fix this? |
Hello,
I understand that Arty A7 is supported, I want to confirm if Arty S7 need something extra to work.
I follow the build instructions and when loading the gateware on Arty S7 I am getting the following error.
I have been digging the code and found that there is a file ./platforms/arty.py which contains the signals and xilinx p/n for Arty A7.
Should be this the starting point to make the port to S7?
I will appreciate your comments,
The text was updated successfully, but these errors were encountered: