[SOLVED] Kernel boot hangs when using dipsw_pio and button_pio on Atlas SoC board

Boot
1

Hello,

I have a problem that I couldn’t solve for the last days on the DE0-nano-SoC CycloneV board.
The kernel does not boot, when I use the device tree that is generated by Altera’s sopc2dts as described here.
My Yocto setup compiled a working device tree binary so I used dtdiff to see what the problem was.
I found out its the Altera GPIO driver (drivers/gpio/gpio-altera.c) mentioned in the dipsw_pio and button_pio sections in the device tree.
When I set status=“disabled” or change the .compatible string in gpio-altera.c so it doesn’t match anymore, the kernel boots. Without the GPIO devices showing up, of course.
There is no output on the UART, even while earlyprintk is active. It just hangs at “Uncompressing Linux… done, booting the kernel.”.
I’m using Kernel 4.1.22-ltsi-rt23-altera because I need the real-time patches, but I tried different Kernels (with and without RT), getting the same result.
I also had to make further changes to the generated dts file to get the FPGA bridge running, but thats a different story.

Any ideas what or where (FPGA or ARM) the problem could be?
Thank you!

2

I (kind of) resolved the problem myself. I switched to using the mainline kernel’s device tree with a little patch to modify base_fpga_region in socfpga.dtsi. The device tree overlay now loads all parts, there are some problems left though.

3

Are you saying that you do not use the device tree produced by the hardware design anymore? How do you generate the device tree overlays from the hardware design? I can’t seem to find much documentation about the device tree overlays; all of the GSRD docs don’t make any mention of the overlays.

4

That’s right.The generated dts does not work anymore and there are too many lines that need to be patched.
It seems Altera does not update the dts generator anymore. You can use the dts file from the mainline kernel which is located somewhere in arch/arm/boot/dts. It describes all of the hard-wired parts which you would need anyway. You just have to remove the base_fpga_region from there, because overlays don’t seem to work for this section as of now (which is possibly a bug, I’m not sure).
In addition to this file, you need an overlay. Documentation is rare.
You can find an example on how to compile the device tree overlay on this page:
link.

5

So is this your development flow now?

  1. compile hardware design to generate fpga image and device tree
  2. manually convert the produced device tree into a device tree overlay
  3. compile the overlay
  4. boot the SoC
  5. load the overlay, which loads the new fpga image

??

6

I would rewrite your second point to “extract sections from the generated device tree to create a new device tree overlay” instead of “manually convert” because 98% of the generated device tree is simply discarded.
Other than that it sounds right!

7

Cool thanks! This seems a weird flow considering the dtc that is included with EDS (I’ve checked 15.1 and 16.0) doesn’t include support for generating overlays. Anyway, thank you much for the help.

EDIT: SoC EDS 16.1 includes dtc that includes symbol/fixup support for creating the overlays.