FIXING THE RAM BRIDGE PROBLEM - A LONG TALE WHOSE END IS NOT YET WRITTEN
I did come across a snippet that suggested an alternate set of commands during U-boot to turn on the F2SDRAM bridge. It still branches to that code in RAM which terminates, suggesting it isn't correctly loaded, but I was hopeful it might have gotten far enough to enable some RAM fetches. Instead, my test program blew up because the H2F LW bridge is now disabled. Somehow I can't get both of the bridges working simultaneously.
Since the defect is in the U-boot startup, I then dove into the rabbit hole of regenerating the preboot and U-boot for the design. In order to do this I had to install quite a few tools that weren't previously on my Linux system. Bison and FLEX, libSSL-dev and according to a few bits of documentation I would need the older Python 2. Then I had to fetch the U-boot source from Github and work through generating everything needed.
Eventually I go everything to cleanly 'make', however the results did NOT include the bridge_enable_handoff and related scripts that actually enable the bridges. More surfing and extensive reading at Rocketboards.org which looks suspiciously like a dumping site where Intel tossed all the System on a Chip stuff they bought from Altera when they lost commercial interest. Not saying it is, but . . .
Some of the articles suggest that part of the process is a python script that will modify the U-boot source tree based on the particular SoC design I have, reading things from a folder in the project that is handoffs from Quartus. Sounded promising until I went to the directories where they said the python scripts would live, and found NOTHING. No scripts. All I can find in the official 'documentation' are references like this that are contradictory between posts and document pages.
One can take the Golden Reference Hardware Design, an example, and generate it EXACTLY as it sits with ease and success. Similarly there are some examples from Altera and from Terasic that other hobbyists simply implement like a formula, without modification, and post on YouTube as videos teaching how to use the SoC environment. Deviate one step and you are on quicksand without enough information to leap to safe ground. Enough ranting, back to my experiments, digging and hoping.
I will hunt to find the source for bridge_enable and bridge_enable_handoff scripts. I will hunt to find the source or at least explanation of what mysterious code is copied to a location in RAM by some other mysterious code or process such that it can be executed from the aforementioned scripts. If I can figure this out I may be able to rescue my current boot SD card or generate an alternative that will work for me.
At last I have enough clues to determine that the preloader is what should have put the proper instructions into RAM at that address that is branched to by U-boot purportedly to configure and turn on the F2SDRAM interface. What this tells me is that I will indeed have to generate the ENTIRE chain of preloader, U-boot , Linux kernel, device tree blob and finally the flattened tree blob for this project.
Secondarily, other clues led to the realization that in spite of what Rocketboard claims, I don't want to use the official U-boot stream from github but instead the special Altera version. This is where the bridge_enable_handoff and other statements are produced.
WORKING WITH OTHER SD CARD BOOT IMAGES
The other images provided by Terasic are for desktop versions, meaning that it uses the HDMI output to provide a full graphical interface on a monitor. The problem with this is that the HDMI hardware is connected to the FPGA side of the chip not straight to Linux, thus it expects logic in the FPGA to handle this. That logic is proprietary IP and thus not available for me to integrate into my design, even if only to ignore it.
Tantalizingly, these versions use a newer U-boot that has the improved bridge_enable command which MAY not blow up. It appears to turn on all the bridges between HPS and FPGA sides of the chip. The challenge is getting this boot of Linux to coexist with my FPGA load of logic.
I spent about an hour hacking various U-boot environmental variables that control the boot process, after swapping in my FPGA output file for theirs. The code to initialize the HDMI interface tried to run and toggle various signals in the FPGA side, probably resulting in a hang. I tried to disable the configuration of the HDMI.
There are hang messages from the port into which the keyboard and mouse are plugged - which I am not using. I might be able to bypass this with physical items, but the device tree for my system does not have the kb and mouse connections hooked to the proper driver. I may have to blend the device tree blobs to get one that will match the Linux kernel but also my FPGA logic and my application requirements. A lot of 'if' involved here but I will keep plugging along.
I do have access to the serial port on the UART to log in and control the Linux image, at least, if I can get it to start with a hacked up SD card in my desired configuration. There are still many permutations of the different variables I can change to try to get Linux to start up with my FPGA logic in control.
The device tree blob includes all the peripherals in use, sets them as enabled or disabled and associates drivers to them. Perhaps I can modify the tree to shut down the use of HDMI and the USB OTG port that supports the mouse and keyboard. If it comes up without those, presumably it won't do bad things on pins of the chip that could affect my FPGA logic.
The results are the same - the flattened tree blob is invalid. This is yet another file that is used by U-boot and generated by building U-boot from scratch. I don't think there is any way to deconstruct and modify an existing one simply to update the device tree blob included within it. It appears that I will have to generate this at the tail end of my soup to nuts, ground up generation of everything.
BUILDING THE SYSTEM FROM SCRATCH
I have found a fairly close guide, but it diverges sometimes from what actually occurs or where files are stored on my system. I downloaded and began generation of the preloader, the device tree blob and the U-boot loader. Generally I will sail along getting exactly what is expected until we run into a wall.
This guide was written to make trivial modifications to the "Golden Hardware Reference Design" which appears to be 99% of the universes approach to working with this SoC - to hack on one of the few designs set up as magic incantations blindly followed, rather than actually documenting what is needed to create real work de novo.
Thus one of the bumps in the road was the recipe suggestion to run the sopc2dts tool of the embedded SOC development kit, which purports to take the design information created by Qsys and Quartus and produce the device tree source. This points to two XML files which provide the key descriptions of all the components on the Terasic DE10-Nano system that are not inside the Cyclone V chip. Most of the peripherals like SPI, I2C, USB and so forth are described in these. They were not put into my project at all by Quartus!
I have to go back to the GHRD demonstration folder, find the two XML files and bring them over manually. Only then can I spit out a device tree source file. Alas, as soon as I tried to turn it into a blob (using the device tree compiler), I received errors about led_pio objects that were invalid. These are the signals set up for the GHRD project but not in mine or in the basic SoC system. I stripped them out and could get a blob file that is hopefully correct.
Parts of the process of generation involve selecting which tree of the github project you want to use - I selected the latest production release of U-boot for example, but when I try to make it I get messages that tell me it is suitable for the successor Stratix and Atria SoC chips but not the Cyclone V. Damn. Now I have to back all this out and figure out the last production release which supports my chip, then redo the work to build my preloader and U-boot.
At each step, guided by lots of rote recipes and documentation which simply points to the GHRD for everything, I run the risk of having picked the wrong release or missed something needed for a real project that is not included in GHRD. Further, all these pieces have to work together properly in order to have an SD Card which boots up a workable Linux with my bridges operational and all the functions like SPI operational. What are the chances?
No comments:
Post a Comment