Yes I agree that since increases the delay fixes this issue the problem is caused by:
"some sort of startup delay". However you are pointing to a grander problem: As the DE0_Nano_SoC is flaged EOL with the DE10_Nano (with hdmi) set as replacement framebuffersupport would be something hard to keep out and. by the time the UIO devices show up. One thing that could be causing > problems is if the FPGA is programmed by U-Boot and then reprogrammed > by the Linux kernel. If anything was talking to the FPGA fabric (like > the HDMI interface or any of the other "extra" logic in the example > designs and not just the HM2 logic) that could trigger BadThings up to > and including a kernel panic or system halt. REmoving the devicetree requirement cleared being able to start machinekit without having to reconfigure the fpga on MK startup,,, fine. But I have tested what happens when you have the display running (linux desktop) and then try to reconfigure the fpga with the same bitfile as loaded by uboot. Result is a blank screen.... THis illustrates that loading/running a different bitfile / machinekit configuration will allways require a reboot when using the local soc display. 1 --> It may be possible to remedy this by reloading the alt_vip_fb driver (loaded as module), and resetting / restarting the x-server. ? 2 --> I have spent some time studying the partial-fpga-reconfiguration docs and it looks doable for me to create a partitioned design with. the main partition containing the display and other qsys cores + - the uio. and a freezable bridge + 1 new partition for each hm2 config. On Thursday, 31 August 2017 23:54:04 UTC+2, Charles Steinkuehler wrote: > > On 8/31/2017 4:01 PM, Michael Brown wrote: > > THat said .. if the signature or board name check fails this should not > > cause any kernel panics requiring a reboot. > > Agreed! > > I haven't replicated your results here so I'm not 100% sure what's > happening, but from my experience the FPGA is programmed and running > by the time the UIO devices show up. One thing that could be causing > problems is if the FPGA is programmed by U-Boot and then reprogrammed > by the Linux kernel. If anything was talking to the FPGA fabric (like > the HDMI interface or any of the other "extra" logic in the example > designs and not just the HM2 logic) that could trigger BadThings up to > and including a kernel panic or system halt. > > It's also possible there's a startup delay in the FPGA reset logic > that's causing the problem. The FPGA may be "running", but still > being held in an internal reset condition. > > -- > Charles Steinkuehler > [email protected] <javascript:> > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
