Hey @sharpertool . I was stuck on this for months. Take a look at some of the stuff here.
(I reopened this question like 3 times when the problem ended up being misconfigured dip switches on my board.) This post has a lot of the elements/details I used to get my system working.
My recommended plan of action would be the following:
-
Replicate what I have done. Get the thing to boot with
linux-socfpga/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts at socfpga-5.5 · altera-opensource/linux-socfpga · GitHub -
Only once that is complete would I start playing with their device tree generator. I would compare to make sure that what it is generating has all the important hard stuff (MAC, etc) in the reference device tree. I also would not rely on it recognizing all of its own (proprietary Altera/Intel IP) peripherals. Even if it does, there is still the matter of ensuring that there is built-in kernel support and that you actually enable it when you build the kernel (I have not done this).
At this point, you will have to deal with your own peripherals. Are you doing custom IP in this design? I do not know if you are able to somehow integrate the Quartus IP development flow into their device tree generator tool. (Maybe you could fill me in on this one).
Obviously the tradeoff is
- How complicated the IP you are using is + driver support - how good the drivers actually are
vs - How quickly you can get something up and running.
For example I do not know if they have a PIO driver in their kernel, but I was trying to light some LEDs on my board. In that case, rather than going through device tree madness and driver kernel build config/platform device driver registration and figuring out how to use their software, I simply used /dev/mem and hit the registers manually. If it is something monstrously complicated like a soft MAC, maybe you go with their driver.
As you probably know, the benefit of loading at u-boot stage is that such kernel drivers can probe during kernel boot and set up/configure devices in the fabric.