Under all circumstances the driver will fail and unload the hal is any of 
the signatures are missing or incorrect
and will sometimes cause a kernel panic, this would IMHO be better to use 
time on solving.

Testing for device-tree overlay loaded or not is redundant overkill IMHO.

Testing for uio driver(s)/ports and signature(s)  is a necessaty.


On Wednesday, 30 August 2017 14:57:50 UTC+2, Charles Steinkuehler wrote:
>
> I think that's the right direction, but I'm not sure just removing the 
> check for DTOV_STAT_APPLIED is safe in all instances.  I'd have to 
> crawl through the hm2_soc code (not enough time right now), but from 
> memory, I think it would be better to pass two strings to the code. 
> One string (mandatory) would indicate the uio device name to use for 
> mapping the memory region and interrupt.  The second (optional) string 
> would indicate a device-tree file to attempt to load/unload. 
>
> So without a device-tree overlay string, the driver will fail to load 
> if it doesn't find the proper uio device.  When passed a device-tree 
> overlay string, the driver should behave as it does now (attempt to 
> load or unload/reload the overlay). 
>
> How does that sound? 
>
> On 8/30/2017 6:22 AM, Michael Brown wrote: 
> > Personaly I think that this would be a more elegant solution, removing 
> the 
> > requirement to Always load the device-tree-overlay at machinekit launch: 
> > 
> > *the-snowwhite/machinekit@*bb33c62 
> > <https://github.com/the-snowwhite/machinekit/commit/bb33c62> 
> > 
> > 
> > On Wednesday, 30 August 2017 09:31:35 UTC+2, Michael Brown wrote: 
> >> 
> >> OK nice 
> >> There were some issues with the original image I have worked them out 
> and 
> >> uploaded new tested images today. 
> >> 
> >> I found a different workaround which I have created an Issue on: 
> >> https://github.com/machinekit/machinekit/issues/1261 
> >> 
> >> Maybe someone can figure out how to mod the hm2_soc_ol driver so the 
> >> machinekit mesa soc can run without forcing the load of the dtbo.. ? 
> >> 
> >> I have commited my DE10_Nano quartus project here: 
> >> https://github.com/machinekit/mksocfpga/pull/88 
> >> 
> >> Meanwhile: 
> >> 
> >> 
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
> >> <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>
>  
>
> >> 
> >> How do I change the template so it only affects the DE10_Nano_FB_Cramps 
> >> dtbo ? 
> >> 
> >> 
> >> 
> >> On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote: 
> >>> 
> >>> Nice!!! 
> >>> 
> >>> To fix the hm2_soc_ol problem, just update the device tree file so it 
> >>> doesn't try to program the FPGA.  Replace (or comment) the 
> >>> "firmware-name" line: 
> >>> 
> >>> 
> >>> 
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
> >>> <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>
>  
>
> >>> 
> >>> ...with a tag indicating the FPGA is programmed already: 
> >>> 
> >>>   external-fpga-config = <1>; 
> >>> 
> >>> This will keep the kernel from trying to (re)program the FPGA when you 
> >>> load the overlay.  Everything else (address ranges, IRQ numbers, etc) 
> >>> should be OK and not need any changes. 
> >>> 
> >>> On 8/29/2017 8:32 AM, Michael Brown wrote: 
> >>>> DE10_Nano hdmi with 1024x768 works 
> >>>> This image also boot directly on the DE0_Nano_SoC without programming 
> >>> the 
> >>>> fpga @boot (tested to work with mk) 
> >>>> 
> >>>> The hm2_soc_ol driver needs an update to be able to accept fpga 
> >>> configured 
> >>>> from u-boot at boot. 
> >>>> 
> >>>> Install notes: 
> >>>> 
> >>> 
> https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
>  
> >>>> 
> >>>> :-) 
> >>>> Michael 
> >>>> 
> >>>> On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
> >>>>> 
> >>>>> Michael Brown <[email protected]> has invited you to *contribute 
> >>>>> to* the following shared folder: 
> >>>>> DE10-DE0-Nano 
> >>>>> < 
> >>> 
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>
>  
>
> >>> 
> >>>>> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
> >>>>> framebuffer 
> >>>>> This image also works with the Atlas (DE0-Nano-Soc) board(tested) 
> >>>>> Open 
> >>>>> < 
> >>> 
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>
>  
>
> >>> 
> >>>>> Google Drive: Have all your files within reach from any device. 
> >>>>> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 
> >>> [image: 
> >>>>> Logo for Google Drive] <https://drive.google.com> 
> >>>>> 
> >>>> 
> >>> 
> >>> 
> >>> -- 
> >>> Charles Steinkuehler 
> >>> [email protected] 
> >>> 
> >> 
> > 
>
>
> -- 
> 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.

Reply via email to