Hi Charles Thanks for the latest merge. I would like to address this elder post and update it with the current state of my explorations, and encourage a test of axis, with the latest rev 2.1 soc image.
On Friday, 1 September 2017 17:58:59 UTC+2, Charles Steinkuehler wrote: > > On 9/1/2017 10:43 AM, [email protected] <javascript:> wrote: > > > > On 01/09/17 15:45, Charles Steinkuehler wrote: > >> ...but since it's already working, I think programming the FPGA via > >> overlays should remain supported for folks who aren't trying to use > >> things like HDMI. > > > > My thoughts for what they are worth. > > > > I would have no intention of ever using HDMI from a board with 1GB > > SDRAM and no GPU. > > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=1046&PartNo=2 > > Yes no gpu however the older vip framereader core is able to act as bus master and utilize the fpga to hps sdram bus, which is a great advancement over the old style bit-banged framebuffers you are refering to. even in the rev 2.0 image without this enhancement axis worked adequately. > > > > I am not sure we should even encourage it by making it available! > > Just asks for loads of "Axis locks up when I load my half billion line > > printer file" threads. > This needs to be tested (again) on he new image. > > I would never recommend using the HDMI out for Axis, that's just > asking for problems. Some of the other light-weight UI's might be OK, > but I doubt it. People forget how slow CPU bit-banged displays can be > (and most of the young folk have never even used one). > > There has been some advancement with sddm - kwin and lxqt > > It certainly needs to be able to be disabled or not used, with > > preferably the inconvenience of reboot etc. being for those seeking to > > use HDMI :-P > > I think HDMI should be disabled by default, or possibly in a text-only > console mode (I could actually see that being useful). I agree > enabling any sort of graphics output ought to require at least a > reboot, and possibly a compile (or installation) of a different FPGA > image. > > This has been solved via different device trees for the de10 nano: only those containing _fb_ activate the framebuffer _fb_hd is for 192x1080 resolution, _fb_ has 1024x760 resolution matching the bitfiles in the #95 pr commit. If you prefer also not to have the detktop gui related files and run console only, you should be able to use the deo_nano sd image with a non _hd_ devicetree. (look at the devicetree utilized upon first-boot in the de10_hdmi instructions, works fine without loading the fpga upon boot). ((I have not tested a machinekit fpga load run in this setup, it is Supposed to work )) I think there are some open-source text-mode displays that could be > compiled into the FPGA that have Linux drivers and could be tied to > the HDMI output... > > ...but again, I'm not particularly worried about getting HDMI output > working at all. I think effort is currently better spent on things > like fixing up the hm2_soc_ol driver and automating the uSD image > creation. > > Yes agree it seem like the deb package building is failing ... atm. :-) > -- > 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.
