Forum Replies Created
- 11th June 2017 at 1:07 pm in reply to: Building the MIPSfpga SoC "project_linux" from scratch #64451
I never did get adding an async reset IP core to resolve that issue. Instead I had to stick with directly migrating the 2014 example project to 2016.2 followed by updating the MIPSfpga core, associating its ports correctly (clock to reset, clock to bus, etc. despite what the documentation stated), and then fixing the duplication that the project upgrade caused with the AHBLite to AXI bus.
That last issue is caused by Vivado sort-of “giving up” as it goes through its IP core upgrades since some of the ports could map to the new AHBLite to AXI bridge and some the versions didn’t match/could migrate without some help (the remapping I described). So because of that, Vivado gives you two half-connected bridges. One is your old one, and the other is a new one. The simple solution I had was to open the project in 2014 and take a screenshot of it so I could compare notes as I “fixed” the upgraded project.
As for the IP core, we were given a 2.0 beta release during the class along with a couple of updates to it, so that’s the core I used. I have no experience with the -plus core other than initially looking at it because it seemed to have some more progress towards peripheral integration. My professor strongly encouraged, instead, using the core we were supplied, so I did.
Class has concluded so I’m no longer actively pursuing this project. The code for my OpenEmbedded layer and Repo Manifest are both still up on github if you would like to continue the effort. You can find them here:
I’ve been told my paper for the class would be published at some point here at the community site. If you would like I can send it over as well. It goes in-depth with the above instructions and how to use the two repos to build the OS.
So far, my attempts at getting a response from the community to accept a pull request/transfer of those repositories has received no response. I plan to leave them up for the foreseeable future, but it never hurts to fork ’em. 😉
And for what it’s worth, I actually lost the OS and the build environment over the course of the last week thanks to a botched Bootcamp Assistant (macOS Sierra) first “repairing” my drive to an un-bootable state, then disk utility “repairing” it until it couldn’t make heads or tails of the fusion drive LV. The only thing I could restore was my macOS side which only has a snapshot of the output products from the project (I can post that somewhere too, it’s about 350 MB).
The GPIO and I2C do work. UIO causes a bus error (same occurs if trying to read via /dev/mem from that address). The Ethernet kind-of works. It seems to correctly read the DTS and load the driver, but ifconfig is unable to load. After a lot of searching, I found a post from someone else using a board powered by USB (as is my situation with the Nexys 4 DDR). For them, they got the same ifconfig error until they swapped to an external power supply (I don’t have one, so I’m unable to test it).
I did not try to rebuild using (your?) buildroot instructions. I was using the base kernel as a proof of life for my bitstream, which of course doesn’t have the rest of the peripherals integrated. I’m unfortunately out of time to go back through each of those labs to see if the buildroot route and patching the 4.1 kernel would work.
Interesting, I hadn’t thought of using those flags. What I ultimately ended up doing was modifying the behavior of the
recipe so that it would skip attempting to discover the alternate root file system (and then mount it) for the sake of booting straight into the already-running file system. This allowed me to get rid of the above flag for forcing a static device mapping in favor of having UDEV available nearer to the beginning. This should (hopefully) facilitate others in adding access to the SD card in some later work.
You can see my progress over on GitHub:
In the next week or two as this course wraps up, I would like to submit a pull request for the first one and change the ownership of the other to the MIPS org. If you’re not familiar with it, the manifest uses Google’s repo utility to stand up a project build area in a rather turn-key manner. Right now, the manifest will not work properly since it will pull from the morty branch of my meta-img rather than my work in progress branch where I’m adding/experimenting with the 2.0 MIPSfpga core and my other changes for the xilfpga.
My current status is that I have all of the MIPSfpga SoC/Part2 patches ported to the 4.8 kernel source, which I’ve designated as the preferred provider for the xilfpga machine. I also added in recipes for LibFDC and the simple GPIO utility/lab, and then referenced them in the INITRAMFS image definition I described in the previous posts. The output of the process is the combined kernel and root file system with everything pre-installed. You load the bit file and then load that binary via GDB and boot it.
So far I get an error with I2C’s driver starting up that it could not locate the clock. Using the suggested command line option to ignore missing clocks did not resolve it. Modifying the device tree element for I2C to reference the 50 MHz clock did, however.
Next up, the simple GPIO example app does not work properly. It throws a bus error:
Data bus error, epc == 34406cf0, ra == 004009a0 Welcome to UIO test prog Opening file /dev/uio0 Trying to mmap memory Writing 0xf at location 0x10C0_0004. 4 LEDs will light up. Bus error
This is interesting because I can use devmem2 to read and write to the GPIO, but trying to communicate with 0x10C0xxxx results in a similar bus error. I’ve double-checked the Address Editor in Vivado, the output device tree I’m using, etc. so I’m not sure where the disconnect is for this custom core.
I had an error relating to bootlogd starting because it needed CONFIG_LEGACY_PTYS set in the kernel configuration. Enabling that resolved the bootlogd error at the cost of nearly doubling the boot up time.
Additionally the ethernet kernel driver appears to load properly and set a MAC, however the follow-on network configuration fails:
Configuring network interfaces… net eth0: of_phy_connect() failed ifconfig: SIOCSIFFLAGS: No such device
I probably will not have time to address either of these in the next couple of weeks as the class ends, and I return the hardware. If either issue looks familiar and you have a suggestion for fixing them, I would be happy to attempt fixing them.
I managed to get my combined kernel+image to boot by specifying a pre-populated /dev. This however threw multiple errors about the RTC not being valid (i.e., that /dev/misc/rtc was invalid, which makes sense because it’s not in the default static /dev).
If anyone has insights on perhaps where I should look to correct this issue with dynamic vs. static (i.e., specifying USE_DEVFS = “0” vs. the default “1”), I would appreciate the insight.29th March 2017 at 11:32 pm in reply to: Building the MIPSfpga SoC "project_linux" from scratch #64453
What I was seeing is that the AHBLite to AXI bridge master would default to 100 MHz and the interconnect S00 and all masters would default to 10 MHz. I went every which way I could think of with connecting things up, but it always ended up this way (even swapping the order in which I connected things).
Last night on a whim I decided to edit my MIPSfpga IP core back in the IP packager. In the original design guide, it says to infer the AHBlite interface, but it never talks about the clock. I figured, why not try the clock?
I selected HCLK, right-clicked, and selected Auto Infer Single Bit Interface -> Clock. I was then greeted with a Vivado warning that FREQ_HZ was not set. Bingo.
Right click HCLK again, and select Edit Interface. Then pick Parameters and add FREQ_HZ for whatever value, 50 MHz is more likely correct given the clock generator configuration, so I set it to 50000000. After repackaging and closing the project, I let Vivado upgrade and re-attempt generating output products. No more FREQ_HZ issues with the interconnect, but I did get issues about async reset warnings.
These async reset warnings about HRESETn and the interconnect can be fixed similarly by marking HRESETn as a reset and then for HCLK, add another attribute pointed back at HRESETn: ASSOCIATED_RESET.
I’m now left with it complaining about the async reset between the MIG and HRESETn.
Thanks, and I hope this helps. 🙂
I started with a fresh installation of Vivado 2014.4, then installed the board_types for the Nexys 4 DDR, etc. I then opened the project and ran it through implementation. The first 4 critical warnings were about the MASTER_TYPE not matching between the blk_mem_gen0/BRAM_PORTA(OTHER) and /axi_bram_ctrl_0/BRAM_PORTA(BRAM_CTRL) (two for 0, and two more for #1). The next 11 critical warnings were things like IOFFS_GEN TX and RX which had IOB=TRUE but were not being driven by an IO element. These were flagged as invalid constraints registers. Once implementation finished, the timing was failing on 11 nets. Those nets were almost all async resets being passed around in the core (these were inter-clock routes).
Consequently, I don’t see it mentioned in the various docs that one needs to load the board files, but I would suspect they’re necessary for the sake of the constraints, etc. The projects also start up with an error if the definitions aren’t installed at the time. It might be worth adding a comment to whichever document it would be appropriate.
Small update — I let Vivado run through to generating the bitstream and was able to get equivalent results in gdb with getting the initial MIPSfpga printed to the screen as well as booting linux. It looks like to me that these false paths just need to be added to the project to quash these, if they are actually ignorable.
Edit: I now see there is a FAQ.txt stating there are critical warnings in these projects and to suggest fixes here on the forum. I don’t know how I overlooked this before. It sounds like this is all expected then. One fix, as mentioned above, is to quash the critical warnings with false path routes or some other constraint to ignore them since they’re inter-clock issues that we know about.