Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

--> 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.
ups I meant

non _fb_ devicetree

On Sunday, 27 May 2018 21:17:37 UTC+2, Michael Brown wrote:
>
> 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, schoo...@btinternet.com 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=205=1046=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 
>> cha...@steinkuehler.net 
>>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

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, schoo...@btinternet.com  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=205=1046=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 
> cha...@steinkuehler.net  
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

I created an issue as placeholder
https://github.com/machinekit/mksocfpga/issues/96


On Sunday, 27 May 2018 20:22:19 UTC+2, Michael Brown wrote:
>
> Hmm quartus build went fine however package building failed with:
>
> Failed to pull Docker image mhaberler/ubker
> FATAL: Failed to pull Docker image mhaberler/ubker
>
> Sounds oddly familiar . 
>
> On Sunday, 27 May 2018 19:49:03 UTC+2, Michael Brown wrote:
>>
>> Thanks for the offer meanwhile Charles found a way to push the merge 
>> button after a look-over 
>> I am looking forward to the feedback on this release... especially on the 
>> performance of the new framebuffer wire-ring... :-)
>>
>> On Sunday, 27 May 2018 16:24:25 UTC+2, Schooner wrote:
>>>
>>>
>>> On 27/05/18 11:26, Michael Brown wrote:
>>>
>>>
>>> I dont know if you are aware that capitalization matters the correct 
>>> filenames are:
>>>
>>> /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf
>>> /lib/firmware/socfpga/DE10_Nano_SoC_FB_DB25.7I76_7I76_7I76_7I76.rbf
>>>  
>>> But these will first be in the socfpga-rbf.deb package a few hours after 
>>> Charles (or someone else) gets around to merging.
>>> :-) 
>>>
>>> You requested review by @cdsteinkuehler, but I have no idea as to his 
>>> availability at present.
>>>
>>> I am happy to merge if you require the files available and we can revert 
>>> if there transpires to be a problem.
>>>
>>>  
>>>  
>>>
>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Thanks for the offer meanwhile Charles found a way to push the merge button 
after a look-over 
I am looking forward to the feedback on this release... especially on the 
performance of the new framebuffer wire-ring... :-)

On Sunday, 27 May 2018 16:24:25 UTC+2, Schooner wrote:
>
>
> On 27/05/18 11:26, Michael Brown wrote:
>
>
> I dont know if you are aware that capitalization matters the correct 
> filenames are:
>
> /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf
> /lib/firmware/socfpga/DE10_Nano_SoC_FB_DB25.7I76_7I76_7I76_7I76.rbf
>  
> But these will first be in the socfpga-rbf.deb package a few hours after 
> Charles (or someone else) gets around to merging.
> :-) 
>
> You requested review by @cdsteinkuehler, but I have no idea as to his 
> availability at present.
>
> I am happy to merge if you require the files available and we can revert 
> if there transpires to be a problem.
>
>  
>  
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Charles Steinkuehler]

On 5/27/2018 9:24 AM, 'schoone...@btinternet.com' via Machinekit wrote:
> 
> On 27/05/18 11:26, Michael Brown wrote:
>>
>> I dont know if you are aware that capitalization matters the correct 
>> filenames 
>> are:
>>
>> /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf
>> /lib/firmware/socfpga/DE10_Nano_SoC_FB_DB25.7I76_7I76_7I76_7I76.rbf
>> But these will first be in the socfpga-rbf.deb package a few hours after 
>> Charles (or someone else) gets around to merging.
>> :-)
>>
> You requested review by @cdsteinkuehler, but I have no idea as to his 
> availability at present.
> 
> I am happy to merge if you require the files available and we can revert if 
> there transpires to be a problem.

Looks OK, merged.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

['schoone...@btinternet.com' via Machinekit]

  
  

On 27/05/18 11:26, Michael Brown wrote:


  

  I dont know if you are aware that capitalization matters
the correct filenames are:
  
  
  /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf
  
  /lib/firmware/socfpga/DE10_Nano_SoC_FB_DB25.7I76_7I76_7I76_7I76.rbf
  
   
  But these will first be in the socfpga-rbf.deb package a
few hours after Charles (or someone else) gets around to
merging.
  :-) 
  

  

You requested review by @cdsteinkuehler, but I have no idea as to
his availability at present.

I am happy to merge if you require the files available and we can
revert if there transpires to be a problem.




  




-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Yes a separate monitor for each system would definitely be to recommend.
But with one monitor I recommend you stay in the usb kermit/putty console 
until it successfully gets down to saying:
(It is not necessary to see the 2 penguins...)


[  OK  ] Started User Manager for UID 111.

Debian GNU/Linux 9 mksocfpga-nano-soc ttyS0

mksocfpga-nano-soc login: 

Then shift to the de10 board hdmi output.
it takes around another 10 secs (after the login message) until the DE10 
Nano HDMI display shows the login screen gui (on first boot it may take up 
to a minute).
---
Since the frame buffer address has been altered:
With the new images you need to wait for the PR to get merged, and the 
hopefully build the new socfpga-rbf debs without problems:
https://github.com/machinekit/mksocfpga/pull/95

Or
pull the latest updates on the pushed (De10 nano soc fb db25) branch and 
then manually re-compile in quartus.

On Sunday, 27 May 2018 06:24:38 UTC+2, mugginsac wrote:
>
> Michael,
>
> I built a uSD from the new image. I tried both my rbf 
> “/lib/firmware/socfpga/DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf” and the 
> one you listed in the instructions 
> “/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_Cap.rbf” I still
>

I dont know if you are aware that capitalization matters the correct 
filenames are:

/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf
/lib/firmware/socfpga/DE10_Nano_SoC_FB_DB25.7I76_7I76_7I76_7I76.rbf
 
But these will first be in the socfpga-rbf.deb package a few hours after 
Charles (or someone else) gets around to merging.
:-) 

> am not getting a display from the HDMI port of the DE10_Nano. I realized 
> that I had missed a crucial instruction earlier, I was not setting 
> FPGA_LOAD_ON_BOOT to 1. The console looks like it is initializing the 
> desktop according to the messages but I don’t see anything on the monitor 
> when I turn off my development system to try and allow the DE10_Nano to 
> control the monitor. I think Monday I will try to get an extra monitor so 
> that each system can have its own.
>
> Alan
>
> On May 26, 2018, at 4:44 PM, Michael Brown  > wrote:
>
> OK
>
> New PR stuff is now in the pipeline,,, please enjoy ... :-)
> images:
> https://drive.google.com/open?id=1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
> HDMI readme:
> https://drive.google.com/open?id=1rLFGJgvm_q9CqeKDvfdKwD5T9ZRUgJaY
> No desktop (console version) readme:
> https://drive.google.com/open?id=1goTy8C6fB2O5MGCEg_sDuG1fZVy63AsE
>
>
> On Saturday, 26 May 2018 23:19:52 UTC+2, Michael Brown wrote:
>>
>> While the former dtb file will enable the display, it will not let you 
>> run machinekit
>> as the name of the uio port is not correct for machinekit use.
>> this mishap is now corrected in this one.
>> ---
>> I am now running the full quartus docker build, and then expect if all 
>> goes well
>> to upload the 2 fresh images, reduce the instructions and push my PR in a 
>> few hours
>> :-)
>>
>> On Saturday, 26 May 2018 19:38:07 UTC+2, Michael Brown wrote:
>>>
>>>
>>>
>>> On Saturday, 26 May 2018 06:36:46 UTC+2, mugginsac wrote:

 I am seeing three errors on the putty console when it starts to load 
 the kernel 
 the first says [failed] Failed to start Load Kernel Modules 
 the second says [failed] Failed to start iSCSI initiator daemon(iscsid) 
 the third says [failed] Failed to start Login to default iSCSI targets 

 Those errors are not important... however:
>>>
>>> I think I know why you are booting to a blank screen:
>>>
>>> In the (former released now online) sd image the framebuffer's address 
>>> was 0x0005_, so that is the setting in that device tree.
>>> I my recent work I have changed to using 0x0003_1000 for the framebuffer 
>>> address.
>>>
>>> So I have attached my current version that will make the hdmi monitor 
>>> work.
>>> Copy this file to the /boot/dtb folder on you sd card overwriting the 
>>> former version.
>>>
>>> --- BTW
>>> I am very close to having and updated image ready for release with:
>>>
>>> -- A speedier framebuffer.
>>> -- A much more simple u boot setup.
>>> -- no missing -dev source files,(due to being built on stretch which has 
>>> a newer qemu version than kde neon 16.04)
>>>
>>>
>>>
 > On May 25, 2018, at 7:11 PM, Charles Steinkuehler <
 cha...@steinkuehler.net> wrote: 
 > 
 > On 5/25/2018 5:28 PM, Condit Alan wrote: 
 >> 
 >> I am thinking about buying a small LCD monitor say (16” 1366x768). 
 >> So that I can have a monitor on the putty console at the same time 
 >> I am trying to see if the de10-nano is booting into the desktop. 
 >> Right now I can’t easily switch between the x86 linux desktop and 
 >> the de10-nano desktop to see if I am being successful or not. When 
 >> I turn off my development box and try to boot the de10-nano 
 >> desktop I am not seeing anything, the monitor just reports no 
 >> signal. 
 > 
 > I recommend always having a 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Condit Alan]

Michael,

I built a uSD from the new image. I tried both my rbf 
“/lib/firmware/socfpga/DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf” and the one 
you listed in the instructions 
“/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_Cap.rbf” I still am not getting 
a display from the HDMI port of the DE10_Nano. I realized that I had missed a 
crucial instruction earlier, I was not setting FPGA_LOAD_ON_BOOT to 1. The 
console looks like it is initializing the desktop according to the messages but 
I don’t see anything on the monitor when I turn off my development system to 
try and allow the DE10_Nano to control the monitor. I think Monday I will try 
to get an extra monitor so that each system can have its own.

Alan

> On May 26, 2018, at 4:44 PM, Michael Brown  wrote:
> 
> OK
> 
> New PR stuff is now in the pipeline,,, please enjoy ... :-)
> images:
> https://drive.google.com/open?id=1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
> HDMI readme:
> https://drive.google.com/open?id=1rLFGJgvm_q9CqeKDvfdKwD5T9ZRUgJaY
> No desktop (console version) readme:
> https://drive.google.com/open?id=1goTy8C6fB2O5MGCEg_sDuG1fZVy63AsE
> 
> 
> On Saturday, 26 May 2018 23:19:52 UTC+2, Michael Brown wrote:
> While the former dtb file will enable the display, it will not let you run 
> machinekit
> as the name of the uio port is not correct for machinekit use.
> this mishap is now corrected in this one.
> ---
> I am now running the full quartus docker build, and then expect if all goes 
> well
> to upload the 2 fresh images, reduce the instructions and push my PR in a few 
> hours
> :-)
> 
> On Saturday, 26 May 2018 19:38:07 UTC+2, Michael Brown wrote:
> 
> 
> On Saturday, 26 May 2018 06:36:46 UTC+2, mugginsac wrote:
> I am seeing three errors on the putty console when it starts to load the 
> kernel 
> the first says [failed] Failed to start Load Kernel Modules 
> the second says [failed] Failed to start iSCSI initiator daemon(iscsid) 
> the third says [failed] Failed to start Login to default iSCSI targets 
> 
> Those errors are not important... however:
> 
> I think I know why you are booting to a blank screen:
> 
> In the (former released now online) sd image the framebuffer's address was 
> 0x0005_, so that is the setting in that device tree.
> I my recent work I have changed to using 0x0003_1000 for the framebuffer 
> address.
> 
> So I have attached my current version that will make the hdmi monitor work.
> Copy this file to the /boot/dtb folder on you sd card overwriting the former 
> version.
> 
> --- BTW
> I am very close to having and updated image ready for release with:
> 
> -- A speedier framebuffer.
> -- A much more simple u boot setup.
> -- no missing -dev source files,(due to being built on stretch which has a 
> newer qemu version than kde neon 16.04)
> 
> 
> 
> > On May 25, 2018, at 7:11 PM, Charles Steinkuehler  > <>> wrote: 
> > 
> > On 5/25/2018 5:28 PM, Condit Alan wrote: 
> >> 
> >> I am thinking about buying a small LCD monitor say (16” 1366x768). 
> >> So that I can have a monitor on the putty console at the same time 
> >> I am trying to see if the de10-nano is booting into the desktop. 
> >> Right now I can’t easily switch between the x86 linux desktop and 
> >> the de10-nano desktop to see if I am being successful or not. When 
> >> I turn off my development box and try to boot the de10-nano 
> >> desktop I am not seeing anything, the monitor just reports no 
> >> signal. 
> > 
> > I recommend always having a UART serial terminal connected, you will 
> > see a lot of errors you would otherwise miss.  And most of the dev 
> > boards (including the DE10) have a Linux console by default on the USB 
> > UART interface. 
> > 
> > -- 
> > Charles Steinkuehler 
> > cha...@steinkuehler.net <> 
> > 
> > -- 
> > website: http://www.machinekit.io  blog: 
> > http://blog.machinekit.io  github: 
> > https://github.com/machinekit  
> > --- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "Machinekit" group. 
> > To unsubscribe from this topic, visit 
> > https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe 
> > . 
> > To unsubscribe from this group and all its topics, send an email to 
> > machinekit+...@googlegroups.com <>. 
> > Visit this group at https://groups.google.com/group/machinekit 
> > . 
> > For more options, visit https://groups.google.com/d/optout 
> > . 
> 
> 
> -- 
> website: http://www.machinekit.io  blog: 
> http://blog.machinekit.io  github: 
> https://github.com/machinekit 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

OK

New PR stuff is now in the pipeline,,, please enjoy ... :-)
images:
https://drive.google.com/open?id=1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
HDMI readme:
https://drive.google.com/open?id=1rLFGJgvm_q9CqeKDvfdKwD5T9ZRUgJaY
No desktop (console version) readme:
https://drive.google.com/open?id=1goTy8C6fB2O5MGCEg_sDuG1fZVy63AsE


On Saturday, 26 May 2018 23:19:52 UTC+2, Michael Brown wrote:
>
> While the former dtb file will enable the display, it will not let you run 
> machinekit
> as the name of the uio port is not correct for machinekit use.
> this mishap is now corrected in this one.
> ---
> I am now running the full quartus docker build, and then expect if all 
> goes well
> to upload the 2 fresh images, reduce the instructions and push my PR in a 
> few hours
> :-)
>
> On Saturday, 26 May 2018 19:38:07 UTC+2, Michael Brown wrote:
>>
>>
>>
>> On Saturday, 26 May 2018 06:36:46 UTC+2, mugginsac wrote:
>>>
>>> I am seeing three errors on the putty console when it starts to load the 
>>> kernel 
>>> the first says [failed] Failed to start Load Kernel Modules 
>>> the second says [failed] Failed to start iSCSI initiator daemon(iscsid) 
>>> the third says [failed] Failed to start Login to default iSCSI targets 
>>>
>>> Those errors are not important... however:
>>
>> I think I know why you are booting to a blank screen:
>>
>> In the (former released now online) sd image the framebuffer's address 
>> was 0x0005_, so that is the setting in that device tree.
>> I my recent work I have changed to using 0x0003_1000 for the framebuffer 
>> address.
>>
>> So I have attached my current version that will make the hdmi monitor 
>> work.
>> Copy this file to the /boot/dtb folder on you sd card overwriting the 
>> former version.
>>
>> --- BTW
>> I am very close to having and updated image ready for release with:
>>
>> -- A speedier framebuffer.
>> -- A much more simple u boot setup.
>> -- no missing -dev source files,(due to being built on stretch which has 
>> a newer qemu version than kde neon 16.04)
>>
>>
>>
>>> > On May 25, 2018, at 7:11 PM, Charles Steinkuehler <
>>> cha...@steinkuehler.net> wrote: 
>>> > 
>>> > On 5/25/2018 5:28 PM, Condit Alan wrote: 
>>> >> 
>>> >> I am thinking about buying a small LCD monitor say (16” 1366x768). 
>>> >> So that I can have a monitor on the putty console at the same time 
>>> >> I am trying to see if the de10-nano is booting into the desktop. 
>>> >> Right now I can’t easily switch between the x86 linux desktop and 
>>> >> the de10-nano desktop to see if I am being successful or not. When 
>>> >> I turn off my development box and try to boot the de10-nano 
>>> >> desktop I am not seeing anything, the monitor just reports no 
>>> >> signal. 
>>> > 
>>> > I recommend always having a UART serial terminal connected, you will 
>>> > see a lot of errors you would otherwise miss.  And most of the dev 
>>> > boards (including the DE10) have a Linux console by default on the USB 
>>> > UART interface. 
>>> > 
>>> > -- 
>>> > Charles Steinkuehler 
>>> > cha...@steinkuehler.net 
>>> > 
>>> > -- 
>>> > website: http://www.machinekit.io blog: http://blog.machinekit.io 
>>> github: https://github.com/machinekit 
>>> > --- 
>>> > You received this message because you are subscribed to a topic in the 
>>> Google Groups "Machinekit" group. 
>>> > To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe. 
>>> > To unsubscribe from this group and all its topics, send an email to 
>>> machinekit+...@googlegroups.com. 
>>> > Visit this group at https://groups.google.com/group/machinekit. 
>>> > For more options, visit https://groups.google.com/d/optout. 
>>>
>>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

While the former dtb file will enable the display, it will not let you run 
machinekit
as the name of the uio port is not correct for machinekit use.
this mishap is now corrected in this one.
---
I am now running the full quartus docker build, and then expect if all goes 
well
to upload the 2 fresh images, reduce the instructions and push my PR in a 
few hours
:-)

On Saturday, 26 May 2018 19:38:07 UTC+2, Michael Brown wrote:
>
>
>
> On Saturday, 26 May 2018 06:36:46 UTC+2, mugginsac wrote:
>>
>> I am seeing three errors on the putty console when it starts to load the 
>> kernel 
>> the first says [failed] Failed to start Load Kernel Modules 
>> the second says [failed] Failed to start iSCSI initiator daemon(iscsid) 
>> the third says [failed] Failed to start Login to default iSCSI targets 
>>
>> Those errors are not important... however:
>
> I think I know why you are booting to a blank screen:
>
> In the (former released now online) sd image the framebuffer's address was 
> 0x0005_, so that is the setting in that device tree.
> I my recent work I have changed to using 0x0003_1000 for the framebuffer 
> address.
>
> So I have attached my current version that will make the hdmi monitor work.
> Copy this file to the /boot/dtb folder on you sd card overwriting the 
> former version.
>
> --- BTW
> I am very close to having and updated image ready for release with:
>
> -- A speedier framebuffer.
> -- A much more simple u boot setup.
> -- no missing -dev source files,(due to being built on stretch which has a 
> newer qemu version than kde neon 16.04)
>
>
>
>> > On May 25, 2018, at 7:11 PM, Charles Steinkuehler <
>> cha...@steinkuehler.net> wrote: 
>> > 
>> > On 5/25/2018 5:28 PM, Condit Alan wrote: 
>> >> 
>> >> I am thinking about buying a small LCD monitor say (16” 1366x768). 
>> >> So that I can have a monitor on the putty console at the same time 
>> >> I am trying to see if the de10-nano is booting into the desktop. 
>> >> Right now I can’t easily switch between the x86 linux desktop and 
>> >> the de10-nano desktop to see if I am being successful or not. When 
>> >> I turn off my development box and try to boot the de10-nano 
>> >> desktop I am not seeing anything, the monitor just reports no 
>> >> signal. 
>> > 
>> > I recommend always having a UART serial terminal connected, you will 
>> > see a lot of errors you would otherwise miss.  And most of the dev 
>> > boards (including the DE10) have a Linux console by default on the USB 
>> > UART interface. 
>> > 
>> > -- 
>> > Charles Steinkuehler 
>> > cha...@steinkuehler.net 
>> > 
>> > -- 
>> > website: http://www.machinekit.io blog: http://blog.machinekit.io 
>> github: https://github.com/machinekit 
>> > --- 
>> > You received this message because you are subscribed to a topic in the 
>> Google Groups "Machinekit" group. 
>> > To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe. 
>> > To unsubscribe from this group and all its topics, send an email to 
>> machinekit+...@googlegroups.com. 
>> > Visit this group at https://groups.google.com/group/machinekit. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


socfpga_cyclone5_de10_nano_fb.dtb
Description: Binary data

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

On Saturday, 26 May 2018 06:36:46 UTC+2, mugginsac wrote:
>
> I am seeing three errors on the putty console when it starts to load the 
> kernel 
> the first says [failed] Failed to start Load Kernel Modules 
> the second says [failed] Failed to start iSCSI initiator daemon(iscsid) 
> the third says [failed] Failed to start Login to default iSCSI targets 
>
> Those errors are not important... however:

I think I know why you are booting to a blank screen:

In the (former released now online) sd image the framebuffer's address was 
0x0005_, so that is the setting in that device tree.
I my recent work I have changed to using 0x0003_1000 for the framebuffer 
address.

So I have attached my current version that will make the hdmi monitor work.
Copy this file to the /boot/dtb folder on you sd card overwriting the 
former version.

--- BTW
I am very close to having and updated image ready for release with:

-- A speedier framebuffer.
-- A much more simple u boot setup.
-- no missing -dev source files,(due to being built on stretch which has a 
newer qemu version than kde neon 16.04)



> > On May 25, 2018, at 7:11 PM, Charles Steinkuehler <
> cha...@steinkuehler.net > wrote: 
> > 
> > On 5/25/2018 5:28 PM, Condit Alan wrote: 
> >> 
> >> I am thinking about buying a small LCD monitor say (16” 1366x768). 
> >> So that I can have a monitor on the putty console at the same time 
> >> I am trying to see if the de10-nano is booting into the desktop. 
> >> Right now I can’t easily switch between the x86 linux desktop and 
> >> the de10-nano desktop to see if I am being successful or not. When 
> >> I turn off my development box and try to boot the de10-nano 
> >> desktop I am not seeing anything, the monitor just reports no 
> >> signal. 
> > 
> > I recommend always having a UART serial terminal connected, you will 
> > see a lot of errors you would otherwise miss.  And most of the dev 
> > boards (including the DE10) have a Linux console by default on the USB 
> > UART interface. 
> > 
> > -- 
> > Charles Steinkuehler 
> > cha...@steinkuehler.net  
> > 
> > -- 
> > website: http://www.machinekit.io blog: http://blog.machinekit.io 
> github: https://github.com/machinekit 
> > --- 
> > You received this message because you are subscribed to a topic in the 
> Google Groups "Machinekit" group. 
> > To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe. 
> > To unsubscribe from this group and all its topics, send an email to 
> machinekit+...@googlegroups.com . 
> > Visit this group at https://groups.google.com/group/machinekit. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


socfpga_cyclone5_de10_nano_uio_fb.dtb
Description: Binary data

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Condit Alan]

Sorry Michael,

I copied the .rbf to lib/firmware/socfpga and I used the full path when I did 
the "setenv bitimage …".

I ran make dtb on the QuartusProject. It produced soc_system.dtb and 
soc_system.dts in the project directory. When I did "env default -f -a" it 
restored the fdtfile to socfpga_cyclone5_de10_nano_fb.dtb and when I tried 
booting it I was able to boot again. 

I wish I understood what the device tree blob is accomplishes, that would make 
it easier to avoid
these errors.

I am thinking about buying a small LCD monitor say (16” 1366x768). So that I 
can have a monitor on the putty console at the same time I am trying to see if 
the de10-nano is booting into the desktop. Right now I can’t easily switch 
between the x86 linux desktop and the de10-nano desktop to see if I am being 
successful or not. When I turn off my development box and try to boot the 
de10-nano desktop I am not seeing anything, the monitor just reports no signal. 

Thanks for your patience,
Alan

> On May 25, 2018, at 2:03 PM, Michael Brown  wrote:
> 
> 
> 
> On Friday, 25 May 2018 20:14:54 UTC+2, mugginsac wrote:
> I did built a new uSD and then did the following:
> setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf
> 
> The bitimage variable needs to contain the full path to the *.rbf file you 
> compiled and placed somewhere on the sd card ie: 
> /boot/DE10_Nano_SoC_FB_DB25.rbf
> (this assumes you copy the current test subject file you quartus compiled 
> from the output_files folder to /boot folder on the sd card)
>  
> 
> setenv fdtfile DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.dtb (renamed from 
> soc_system.dtb)
> 
> No no no
> where are you getting soc_system.dtb from ... not my instructions.
> 
> You need to use a sutable kernel compiled .dtb file from the /boot/dtb 
> folder. (name something like: DE10_Nano_FB).
> The exact same dtb file as named in the instructions for the demo image... OK 
> ?
> 
>  
> and the result was that I couldn't boot at all.
> So I reset the environment to default and started over.
> I set the ethaddr, hostname, saveenv and tested the boot process and I could 
> boot again.
> Then I did
> setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf
> saveenv 
> and could still boot.
> So the question is do I need to change the fdtfile and if so what with?
> 
> -- 
> website: http://www.machinekit.io  blog: 
> http://blog.machinekit.io  github: 
> https://github.com/machinekit 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Machinekit" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> machinekit+unsubscr...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/machinekit 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

On Friday, 25 May 2018 20:14:54 UTC+2, mugginsac wrote:
>
> I did built a new uSD and then did the following:
> setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf
>

The bitimage variable needs to contain the full path to the *.rbf file you 
compiled and placed somewhere on the sd card ie: 
/boot/DE10_Nano_SoC_FB_DB25.rbf
(this assumes you copy the current test subject file you quartus compiled 
from the output_files folder to /boot folder on the sd card)
 

>
> setenv fdtfile DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.dtb (renamed from 
> soc_system.dtb)
>

No no no
where are you getting soc_system.dtb from ... not my instructions.

You need to use a sutable kernel compiled .dtb file from the /boot/dtb 
folder. (name something like: DE10_Nano_FB).
The exact same dtb file as named in the instructions for the demo image... 
OK ?

 

> and the result was that I couldn't boot at all.
> So I reset the environment to default and started over.
> I set the ethaddr, hostname, saveenv and tested the boot process and I 
> could boot again.
> Then I did
> setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf
> saveenv 
> and could still boot.
> So the question is do I need to change the fdtfile and if so what with?
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

I did built a new uSD and then did the following:
setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf 
setenv fdtfile DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.dtb (renamed from 
soc_system.dtb)
and the result was that I couldn't boot at all.
So I reset the environment to default and started over.
I set the ethaddr, hostname, saveenv and tested the boot process and I 
could boot again.
Then I did
setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf
saveenv 
and could still boot.
So the question is do I need to change the fdtfile and if so what with?

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Yes make scrub_clean will wipe out the firmware.mif file and also the .vhd 
config file. these files are easiest regenerated by running build.sh in the 
quartus docker image, this is why I copied these files over with an 
explicit note message in the commit list to make that clear.
After scrub clean you can "just" checkout the missing files from git.
The cv-ip folder name is due to mksocfpga contains multiple board configs 
for both Xilinx and Altera / intelfpga

On Thursday, 24 May 2018 06:31:16 UTC+2, mugginsac wrote:
>
> OK, the build was successful again this time. So it appears to me that 
> something is being wiped out during “make scrub_clean” that causes the next 
> build to fail testing. Because it completed the compile both times but 
> didn’t complete the build script after the “make scrub_clean”. I hope this 
> makes sense to somebody because I am confused at the moment. 
>
> Tomorrow I will try to test the generated .rbf file.

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

OK, the build was successful again this time. So it appears to me that 
something is being wiped out during “make scrub_clean” that causes the next 
build to fail testing. Because it completed the compile both times but didn’t 
complete the build script after the “make scrub_clean”. I hope this makes sense 
to somebody because I am confused at the moment.

Tomorrow I will try to test the generated .rbf file.

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

I have gotten DE10_Nano_FB_25 with Michael's mods to build but I have yet 
to test it. After it built successfully, (since I was going to be gone all 
day anyway) I did "make scrub_clean" and tried running build again, 
however, this time it failed in Synthesis. I am running "./build.sh 
7I76_7I76_7I76_7I76" again to see if it is just something about running 
build after "make scrub_clean" that has a problem. Anyway, I saved the 
folder after the successful build so that I can actually try testing the 
"DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf".

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

*Never mind, I found the answer to my question, it is already cv_ip in 
mksocfpga.*
On Wednesday, May 23, 2018 at 4:09:50 PM UTC-7, mugginsac wrote:
>
> Michael,
>
> What is gained by renaming the "ip" directory to "cv_ip"? 
>
> What is lost is the ease in incorporating the changes back into 
> "mksocfpga" master. Either every project that uses "ip" directory would 
> have to be edited to use "cv_ip" or one would have to maintain both "ip" 
> and "cv_ip" directories with mostly duplicate sources. 
>
> So do the benefits of the change outweigh the costs?
>
> Alan
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

Michael,

I found an error and I was trying to figure out what the problem was, but 
your latest fix, seems to have solved the problem.
I am rebuilding and I will know for sure in a bit.

Thanks,
Alan

On Sunday, May 20, 2018 at 5:09:59 AM UTC-7, Michael Brown wrote:
>
> OK
> DE10_Nano_SoC_FB_DB25 project is now finished, compilable and ready for 
> testing:
>
> The default bitfile compiled is the PIN_7I76_7I76_7I76_7I76
>
> https://github.com/the-snowwhite/mksocfpga/tree/DE10_Nano_SoC_FB_DB25
>
> I will first be able to test the project this evening (in 4-6 hours).
> You are very welcome to scrutinize and test in the meanwhile
>
>
> On Sunday, 20 May 2018 03:32:32 UTC+2, Michael Brown wrote:
>>
>> It seems like you are trying to do too many things at once and then it 
>> gets too over complicated:
>> (the systemverilog Cramps version is core reduced only including the 
>> hm2cores needed for the cramps board)
>> (TODO: It is intended to later evolve with a systemverilog based config 
>> system, hence the hostmot3 name )
>>
>> First step is to make a DE10 Nano version of the DE0_Nano_SoC_DB25:
>> Since explaining has fallen short of the mark I have initiated the port 
>> of the fullcore vhdl version in the link below:
>>
>> Look carefully through the to 6 commits here:
>>
>> https://github.com/the-snowwhite/mksocfpga/commits/DE10_Nano_SoC_FB_DB25 
>>
>> I have cheated a little and kept the video cores in the qsys system, so 
>> the last commits do not compile fully,
>> until the video wiring is sorted out.
>> After that last step should be to add the hdmi config files to the top 
>> .vhd file.
>>
>> The end result will use the same device tree (.dtb file), uboot ,rootfs 
>> and no_fw hm2 hal config setup as the DE10_Nano_FB_Cramps. ( only 
>> difference is the DE10_Nano_FB_DB25*.rbf bitfiles of course) :-)
>>
>> I expect to have a commit ready within a few days unless someone else 
>> beats me to it.
>>
>> Question to ponder:
>> It is not yet possible (for me) to support more than 1 screen resolution 
>> pr bitfile , right now it is 1024x768x8bpp.
>> Do you prefer a different screen resolution (up to hd) ?
>>
>>
>> On Thursday, 17 May 2018 02:01:35 UTC+2, mugginsac wrote:
>>>
>>> I am trying to figure out exactly what I need to do to get the 
>>> DE10_Nano_FB_DB25 to run with the HDMI console. The problem is that 
>>> Charles' DE0_Nano_Soc_DB25 uses VHDL and Michael's DE10_Nano_FB_Cramps uses 
>>> SYSTEM_VERILOG. And Charles' uses hostmot2_cfg.vhd while Michael is using 
>>> hostmot3_cfg.vhd. So there are no files that I can compare directly and say 
>>> "Oh, I just need to add 'X' to file 'y' inorder to fix the problem". I was 
>>> able to get the DE10_Nano to boot using the Putty console under another 
>>> version of Linux but not to bring up the HDMI console from the DE10-Nano.
>>>
>>> So I see three options:
>>> 1. I use hostmot3_cfg.vhd and the SYSTEM_VERILOG stuff from 
>>> DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv and create a PIN_ 
>>> file for the 7I76 compatible with hostmote_cfg, or
>>> 2. I keep using hostmot2_cfg.vhd and translate/add the missing HDMI 
>>> stuff from DE10_NANO_FB_CRAMPS.sv to the DE10_NANO_FB_DB25.vhd file, or
>>> 3. I keep using hostmot2_cfg.vhd and translate/add the missing PIN DESC 
>>> stuff from DE10_NANO_FB_DB25.vhd to the SYSTEM_VERILOG file 
>>> DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv (this seems easier 
>>> to me).
>>>
>>> Do any of these make any sense? What am I missing?
>>>
>>> Thanks,
>>> Alan
>>>
>>>
>>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

OK
DE10_Nano_SoC_FB_DB25 project is now finished, compilable and ready for 
testing:

The default bitfile compiled is the PIN_7I76_7I76_7I76_7I76

https://github.com/the-snowwhite/mksocfpga/tree/DE10_Nano_SoC_FB_DB25

I will first be able to test the project this evening (in 4-6 hours).
You are very welcome to scrutinize and test in the meanwhile


On Sunday, 20 May 2018 03:32:32 UTC+2, Michael Brown wrote:
>
> It seems like you are trying to do too many things at once and then it 
> gets too over complicated:
> (the systemverilog Cramps version is core reduced only including the 
> hm2cores needed for the cramps board)
> (TODO: It is intended to later evolve with a systemverilog based config 
> system, hence the hostmot3 name )
>
> First step is to make a DE10 Nano version of the DE0_Nano_SoC_DB25:
> Since explaining has fallen short of the mark I have initiated the port of 
> the fullcore vhdl version in the link below:
>
> Look carefully through the to 6 commits here:
>
> https://github.com/the-snowwhite/mksocfpga/commits/DE10_Nano_SoC_FB_DB25 
>
> I have cheated a little and kept the video cores in the qsys system, so 
> the last commits do not compile fully,
> until the video wiring is sorted out.
> After that last step should be to add the hdmi config files to the top 
> .vhd file.
>
> The end result will use the same device tree (.dtb file), uboot ,rootfs 
> and no_fw hm2 hal config setup as the DE10_Nano_FB_Cramps. ( only 
> difference is the DE10_Nano_FB_DB25*.rbf bitfiles of course) :-)
>
> I expect to have a commit ready within a few days unless someone else 
> beats me to it.
>
> Question to ponder:
> It is not yet possible (for me) to support more than 1 screen resolution 
> pr bitfile , right now it is 1024x768x8bpp.
> Do you prefer a different screen resolution (up to hd) ?
>
>
> On Thursday, 17 May 2018 02:01:35 UTC+2, mugginsac wrote:
>>
>> I am trying to figure out exactly what I need to do to get the 
>> DE10_Nano_FB_DB25 to run with the HDMI console. The problem is that 
>> Charles' DE0_Nano_Soc_DB25 uses VHDL and Michael's DE10_Nano_FB_Cramps uses 
>> SYSTEM_VERILOG. And Charles' uses hostmot2_cfg.vhd while Michael is using 
>> hostmot3_cfg.vhd. So there are no files that I can compare directly and say 
>> "Oh, I just need to add 'X' to file 'y' inorder to fix the problem". I was 
>> able to get the DE10_Nano to boot using the Putty console under another 
>> version of Linux but not to bring up the HDMI console from the DE10-Nano.
>>
>> So I see three options:
>> 1. I use hostmot3_cfg.vhd and the SYSTEM_VERILOG stuff from 
>> DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv and create a PIN_ 
>> file for the 7I76 compatible with hostmote_cfg, or
>> 2. I keep using hostmot2_cfg.vhd and translate/add the missing HDMI stuff 
>> from DE10_NANO_FB_CRAMPS.sv to the DE10_NANO_FB_DB25.vhd file, or
>> 3. I keep using hostmot2_cfg.vhd and translate/add the missing PIN DESC 
>> stuff from DE10_NANO_FB_DB25.vhd to the SYSTEM_VERILOG file 
>> DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv (this seems easier 
>> to me).
>>
>> Do any of these make any sense? What am I missing?
>>
>> Thanks,
>> Alan
>>
>>
>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

It seems like you are trying to do too many things at once and then it gets 
too over complicated:
(the systemverilog Cramps version is core reduced only including the 
hm2cores needed for the cramps board)
(TODO: It is intended to later evolve with a systemverilog based config 
system, hence the hostmot3 name )

First step is to make a DE10 Nano version of the DE0_Nano_SoC_DB25:
Since explaining has fallen short of the mark I have initiated the port of 
the fullcore vhdl version in the link below:

Look carefully through the to 6 commits here:

https://github.com/the-snowwhite/mksocfpga/commits/DE10_Nano_SoC_FB_DB25 

I have cheated a little and kept the video cores in the qsys system, so the 
last commits do not compile fully,
until the video wiring is sorted out.
After that last step should be to add the hdmi config files to the top .vhd 
file.

The end result will use the same device tree (.dtb file), uboot ,rootfs and 
no_fw hm2 hal config setup as the DE10_Nano_FB_Cramps. ( only difference is 
the DE10_Nano_FB_DB25*.rbf bitfiles of course) :-)

I expect to have a commit ready within a few days unless someone else beats 
me to it.

Question to ponder:
It is not yet possible (for me) to support more than 1 screen resolution pr 
bitfile , right now it is 1024x768x8bpp.
Do you prefer a different screen resolution (up to hd) ?


On Thursday, 17 May 2018 02:01:35 UTC+2, mugginsac wrote:
>
> I am trying to figure out exactly what I need to do to get the 
> DE10_Nano_FB_DB25 to run with the HDMI console. The problem is that 
> Charles' DE0_Nano_Soc_DB25 uses VHDL and Michael's DE10_Nano_FB_Cramps uses 
> SYSTEM_VERILOG. And Charles' uses hostmot2_cfg.vhd while Michael is using 
> hostmot3_cfg.vhd. So there are no files that I can compare directly and say 
> "Oh, I just need to add 'X' to file 'y' inorder to fix the problem". I was 
> able to get the DE10_Nano to boot using the Putty console under another 
> version of Linux but not to bring up the HDMI console from the DE10-Nano.
>
> So I see three options:
> 1. I use hostmot3_cfg.vhd and the SYSTEM_VERILOG stuff from 
> DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv and create a PIN_ 
> file for the 7I76 compatible with hostmote_cfg, or
> 2. I keep using hostmot2_cfg.vhd and translate/add the missing HDMI stuff 
> from DE10_NANO_FB_CRAMPS.sv to the DE10_NANO_FB_DB25.vhd file, or
> 3. I keep using hostmot2_cfg.vhd and translate/add the missing PIN DESC 
> stuff from DE10_NANO_FB_DB25.vhd to the SYSTEM_VERILOG file 
> DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv (this seems easier 
> to me).
>
> Do any of these make any sense? What am I missing?
>
> Thanks,
> Alan
>
>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

I am trying to figure out exactly what I need to do to get the 
DE10_Nano_FB_DB25 to run with the HDMI console. The problem is that 
Charles' DE0_Nano_Soc_DB25 uses VHDL and Michael's DE10_Nano_FB_Cramps uses 
SYSTEM_VERILOG. And Charles' uses hostmot2_cfg.vhd while Michael is using 
hostmot3_cfg.vhd. So there are no files that I can compare directly and say 
"Oh, I just need to add 'X' to file 'y' inorder to fix the problem". I was 
able to get the DE10_Nano to boot using the Putty console under another 
version of Linux but not to bring up the HDMI console from the DE10-Nano.

So I see three options:
1. I use hostmot3_cfg.vhd and the SYSTEM_VERILOG stuff from 
DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv and create a PIN_ 
file for the 7I76 compatible with hostmote_cfg, or
2. I keep using hostmot2_cfg.vhd and translate/add the missing HDMI stuff 
from DE10_NANO_FB_CRAMPS.sv to the DE10_NANO_FB_DB25.vhd file, or
3. I keep using hostmot2_cfg.vhd and translate/add the missing PIN DESC 
stuff from DE10_NANO_FB_DB25.vhd to the SYSTEM_VERILOG file 
DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv (this seems easier 
to me).

Do any of these make any sense? What am I missing?

Thanks,
Alan


-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Great
Thanks for the feedback.

On Sun, May 13, 2018, 22:36 mugginsac  wrote:

> I could say well it used to work, but the truth is that I forgot that I
> had added another router/switch into my network and I forgot to take that
> into account. Now it is working. Thanks for the help.
>
> Alan
>
> On Wednesday, May 9, 2018 at 4:26:29 PM UTC-7, Michael Brown wrote:
>>
>> Ok. The DHCP fix must be in the updated image.
>> If you are only able to ssh by using the ip address this can be due to
>> DNS server setup on your local lan router.
>>
>>
>> On Thu, May 10, 2018, 00:34 mugginsac  wrote:
>>
>>> I see two addresses. One for the ethernet 10.xx.xx.xx and 127.0.0.1 for
>>> local.
>>>
>>> On Tuesday, May 8, 2018 at 9:02:28 AM UTC-7, Michael Brown wrote:

 Ups forgot reply all:
 Honestly I do not remember and I may have made a typo in the package
 name.
 What matters first is:
 When you run the ifconfig command how many up addresses do you see ?
 ..:-)
 BTW.
 You can also look in the leases list on the DHCP server on your local
 network.

 On Tue, May 8, 2018, 00:02 mugginsac  wrote:

> Michael,
>
> I tried your suggestion but apt reported dhcpcd5 not found. Did you
> take it out before you built the last uSD image?
>
> Thanks,
> Alan
>
> On Sunday, May 6, 2018 at 4:09:36 AM UTC-7, Michael Brown wrote:
>>
>> I found 1 quirk in the image:
>> If you do a ifconfig in the image you will probably see more than 1
>> ip address which gives strange
>>  login behavior. the solution to this is to remove the dhcpcd5
>> package.
>>
>> sudo apt purge dhcpcd5
>>
>>
>>
>>

 --
> website: http://www.machinekit.io blog: http://blog.machinekit.io
> github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> machinekit+...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> website: http://www.machinekit.io blog: http://blog.machinekit.io
>>> github: https://github.com/machinekit
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Machinekit" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> machinekit+...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/machinekit.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

I could say well it used to work, but the truth is that I forgot that I had 
added another router/switch into my network and I forgot to take that into 
account. Now it is working. Thanks for the help.

Alan

On Wednesday, May 9, 2018 at 4:26:29 PM UTC-7, Michael Brown wrote:
>
> Ok. The DHCP fix must be in the updated image.
> If you are only able to ssh by using the ip address this can be due to DNS 
> server setup on your local lan router.
>
>
> On Thu, May 10, 2018, 00:34 mugginsac  
> wrote:
>
>> I see two addresses. One for the ethernet 10.xx.xx.xx and 127.0.0.1 for 
>> local.
>>
>> On Tuesday, May 8, 2018 at 9:02:28 AM UTC-7, Michael Brown wrote:
>>>
>>> Ups forgot reply all:
>>> Honestly I do not remember and I may have made a typo in the package 
>>> name.
>>> What matters first is:
>>> When you run the ifconfig command how many up addresses do you see ? 
>>> ..:-)
>>> BTW.
>>> You can also look in the leases list on the DHCP server on your local 
>>> network.
>>>
>>> On Tue, May 8, 2018, 00:02 mugginsac  wrote:
>>>
 Michael,

 I tried your suggestion but apt reported dhcpcd5 not found. Did you 
 take it out before you built the last uSD image?

 Thanks,
 Alan

 On Sunday, May 6, 2018 at 4:09:36 AM UTC-7, Michael Brown wrote:
>
> I found 1 quirk in the image:
> If you do a ifconfig in the image you will probably see more than 1 ip 
> address which gives strange
>  login behavior. the solution to this is to remove the dhcpcd5 
> package. 
>
> sudo apt purge dhcpcd5
>
>
>
>
>>>
>>> -- 
 website: http://www.machinekit.io blog: http://blog.machinekit.io 
 github: https://github.com/machinekit
 --- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "Machinekit" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 machinekit+...@googlegroups.com.
 Visit this group at https://groups.google.com/group/machinekit.
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> website: http://www.machinekit.io blog: http://blog.machinekit.io 
>> github: https://github.com/machinekit
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Machinekit" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> machinekit+...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Ok. The DHCP fix must be in the updated image.
If you are only able to ssh by using the ip address this can be due to DNS
server setup on your local lan router.


On Thu, May 10, 2018, 00:34 mugginsac  wrote:

> I see two addresses. One for the ethernet 10.xx.xx.xx and 127.0.0.1 for
> local.
>
> On Tuesday, May 8, 2018 at 9:02:28 AM UTC-7, Michael Brown wrote:
>>
>> Ups forgot reply all:
>> Honestly I do not remember and I may have made a typo in the package name.
>> What matters first is:
>> When you run the ifconfig command how many up addresses do you see ? ..:-)
>> BTW.
>> You can also look in the leases list on the DHCP server on your local
>> network.
>>
>> On Tue, May 8, 2018, 00:02 mugginsac  wrote:
>>
>>> Michael,
>>>
>>> I tried your suggestion but apt reported dhcpcd5 not found. Did you take
>>> it out before you built the last uSD image?
>>>
>>> Thanks,
>>> Alan
>>>
>>> On Sunday, May 6, 2018 at 4:09:36 AM UTC-7, Michael Brown wrote:

 I found 1 quirk in the image:
 If you do a ifconfig in the image you will probably see more than 1 ip
 address which gives strange
  login behavior. the solution to this is to remove the dhcpcd5 package.

 sudo apt purge dhcpcd5




>>
>> --
>>> website: http://www.machinekit.io blog: http://blog.machinekit.io
>>> github: https://github.com/machinekit
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Machinekit" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> machinekit+...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/machinekit.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

I see two addresses. One for the ethernet 10.xx.xx.xx and 127.0.0.1 for 
local.

On Tuesday, May 8, 2018 at 9:02:28 AM UTC-7, Michael Brown wrote:
>
> Ups forgot reply all:
> Honestly I do not remember and I may have made a typo in the package name.
> What matters first is:
> When you run the ifconfig command how many up addresses do you see ? ..:-)
> BTW.
> You can also look in the leases list on the DHCP server on your local 
> network.
>
> On Tue, May 8, 2018, 00:02 mugginsac  
> wrote:
>
>> Michael,
>>
>> I tried your suggestion but apt reported dhcpcd5 not found. Did you take 
>> it out before you built the last uSD image?
>>
>> Thanks,
>> Alan
>>
>> On Sunday, May 6, 2018 at 4:09:36 AM UTC-7, Michael Brown wrote:
>>>
>>> I found 1 quirk in the image:
>>> If you do a ifconfig in the image you will probably see more than 1 ip 
>>> address which gives strange
>>>  login behavior. the solution to this is to remove the dhcpcd5 package. 
>>>
>>> sudo apt purge dhcpcd5
>>>
>>>
>>>
>>>
>
> -- 
>> website: http://www.machinekit.io blog: http://blog.machinekit.io 
>> github: https://github.com/machinekit
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Machinekit" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> machinekit+...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Ups forgot reply all:
Honestly I do not remember and I may have made a typo in the package name.
What matters first is:
When you run the ifconfig command how many up addresses do you see ? ..:-)
BTW.
You can also look in the leases list on the DHCP server on your local
network.

On Tue, May 8, 2018, 00:02 mugginsac  wrote:

> Michael,
>
> I tried your suggestion but apt reported dhcpcd5 not found. Did you take
> it out before you built the last uSD image?
>
> Thanks,
> Alan
>
> On Sunday, May 6, 2018 at 4:09:36 AM UTC-7, Michael Brown wrote:
>>
>> I found 1 quirk in the image:
>> If you do a ifconfig in the image you will probably see more than 1 ip
>> address which gives strange
>>  login behavior. the solution to this is to remove the dhcpcd5 package.
>>
>> sudo apt purge dhcpcd5
>>
>>
>>
>>

 --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

BTW
I'm sorry that there is not some nice documentation I can point at 
describing how to add a new project,
but here are some notes that have survived:
https://github.com/machinekit/mksocfpga/tree/master/docs


On Wednesday, 18 April 2018 01:25:06 UTC+2, Michael Brown wrote:
>
>
> Stop ... hold
> On Tuesday, 17 April 2018 05:18:20 UTC+2, mugginsac wrote:
>>
>> Michael,
>>
>> I have set up a quarts project DE10_Nano_FB_DB25 based on Charles 
>> DE0_Nano_DB25 project.
>>
>
> This is a recipe for disaster.
>
> ---
>
> The process is in crude steps:
>
> You need to start with a DE10_Nano_Soc Board design (ie: the 
> DE10_Nano_FB_Cramps)
>
> Then the systemverilog .sv topfile  can be replaced with the vhdl .v one 
> from the DE0_Nano_DB25.
>
> The HDMI framebuffer core is in the Qsys design (in the 
> DE10_Nano_FB_Cramps project), also the lcd clock is placed into the qsys 
> partition.
>
>  
>
>> I copied the HDMI stuff from your DE10_Nano_FB_Cramps.qsf into 
>> DE0_Nano_DB25.qsf to create DE10_Nano_FB_DB25.qsf. There were pin conflicts 
>> between the HDMI stuff and the GPIO stuff. So I copied the GPIO stuff from 
>> your DE10_Nano_FB_Cramps.qsf as well, but then I got to wondering if that 
>> was the right thing to do? Should I have preserved the GPIO pins and 
>> changed the HDMI pins to resolve the conflicts?
>>
>>
> Do not edit any pins in the .qsf file these pins are set up for the 
> physical boards and the DE0 nano is very different from the DE10 Nano, so 
> you will only get no-go or smoke...!
>
> You have to have some basic knowledge about fpga's verilog/vhdl and 
> working with Quartus and qsys for this attempt to succeed, I would not 
> recommend you to continue anything like you are describing   
>  
> ---
>  
>
>> Thanks,
>> Alan
>>
>> On Apr 16, 2018, at 7:00 PM, Michael Brown  wrote:
>>
>> Short answer ... Yes
>>
>> more verbose:
>> Each board needs its own Quartus project folder.
>>
>> There are 2 options:
>>
>> 1.
>> To create that bitfile a new quartus project targeting the DE10 Nano 
>> Board with DB25 adaptor,
>> needs to be added here:
>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects
>>
>> With a name like:
>> DE10_Nano_FB_DB25
>> Based on the existing _DB25 Quartus project by Charles
>> 2.
>> As a last resort
>> I can add a 7I76_7I76_7I76_7I76 pin file to the 
>> existing DE10_Nano_FB_Cramps quartus project
>> and create it with a DE10_Nano_FB name and then add something to get the 
>> built in pin mux to configure for the DB25
>> Also needed would be to add the SSerial core.
>> (This will take some time as I'm caught up in updating and debugging my 
>> synthesizer project)
>>
>>
>> On Monday, 16 April 2018 20:26:39 UTC+2, mugginsac wrote:
>>>
>>> Michael,
>>>
>>> I followed your instructions down to:
>>>
>>> setenv bitimage 
>>> /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_spi.rbf
>>> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
>>>
>>> It looks to me like I need something like: 
>>>
>>> setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_DB25.rbf
>>> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
>>>
>>> It looks like the socfpga_cyclone5_de10_nano_fb.dtb may already exist 
>>> but that I need to create the DE10_Nano_FB_DB25.rbf.
>>>
>>> Is that right?
>>>
>>
>> -- 
>> website: http://www.machinekit.io blog: http://blog.machinekit.io 
>> github: https://github.com/machinekit
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Machinekit" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> machinekit+...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Stop ... hold
On Tuesday, 17 April 2018 05:18:20 UTC+2, mugginsac wrote:
>
> Michael,
>
> I have set up a quarts project DE10_Nano_FB_DB25 based on Charles 
> DE0_Nano_DB25 project.
>

This is a recipe for disaster.

---

The process is in crude steps:

You need to start with a DE10_Nano_Soc Board design (ie: the 
DE10_Nano_FB_Cramps)

Then the systemverilog .sv topfile  can be replaced with the vhdl .v one 
from the DE0_Nano_DB25.

The HDMI framebuffer core is in the Qsys design (in the DE10_Nano_FB_Cramps 
project), also the lcd clock is placed into the qsys partition.

 

> I copied the HDMI stuff from your DE10_Nano_FB_Cramps.qsf into 
> DE0_Nano_DB25.qsf to create DE10_Nano_FB_DB25.qsf. There were pin conflicts 
> between the HDMI stuff and the GPIO stuff. So I copied the GPIO stuff from 
> your DE10_Nano_FB_Cramps.qsf as well, but then I got to wondering if that 
> was the right thing to do? Should I have preserved the GPIO pins and 
> changed the HDMI pins to resolve the conflicts?
>
>
Do not edit any pins in the .qsf file these pins are set up for the 
physical boards and the DE0 nano is very different from the DE10 Nano, so 
you will only get no-go or smoke...!

You have to have some basic knowledge about fpga's verilog/vhdl and working 
with Quartus and qsys for this attempt to succeed, I would not recommend 
you to continue anything like you are describing   
 
---
 

> Thanks,
> Alan
>
> On Apr 16, 2018, at 7:00 PM, Michael Brown  > wrote:
>
> Short answer ... Yes
>
> more verbose:
> Each board needs its own Quartus project folder.
>
> There are 2 options:
>
> 1.
> To create that bitfile a new quartus project targeting the DE10 Nano Board 
> with DB25 adaptor,
> needs to be added here:
> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects
>
> With a name like:
> DE10_Nano_FB_DB25
> Based on the existing _DB25 Quartus project by Charles
> 2.
> As a last resort
> I can add a 7I76_7I76_7I76_7I76 pin file to the 
> existing DE10_Nano_FB_Cramps quartus project
> and create it with a DE10_Nano_FB name and then add something to get the 
> built in pin mux to configure for the DB25
> Also needed would be to add the SSerial core.
> (This will take some time as I'm caught up in updating and debugging my 
> synthesizer project)
>
>
> On Monday, 16 April 2018 20:26:39 UTC+2, mugginsac wrote:
>>
>> Michael,
>>
>> I followed your instructions down to:
>>
>> setenv bitimage 
>> /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_spi.rbf
>> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
>>
>> It looks to me like I need something like: 
>>
>> setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_DB25.rbf
>> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
>>
>> It looks like the socfpga_cyclone5_de10_nano_fb.dtb may already exist but 
>> that I need to create the DE10_Nano_FB_DB25.rbf.
>>
>> Is that right?
>>
>
> -- 
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
> https://github.com/machinekit
> --- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> machinekit+...@googlegroups.com .
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Condit Alan]

Michael,

I have set up a quarts project DE10_Nano_FB_DB25 based on Charles DE0_Nano_DB25 
project.

I copied the HDMI stuff from your DE10_Nano_FB_Cramps.qsf into 
DE0_Nano_DB25.qsf to create DE10_Nano_FB_DB25.qsf. There were pin conflicts 
between the HDMI stuff and the GPIO stuff. So I copied the GPIO stuff from your 
DE10_Nano_FB_Cramps.qsf as well, but then I got to wondering if that was the 
right thing to do? Should I have preserved the GPIO pins and changed the HDMI 
pins to resolve the conflicts?

Thanks,
Alan

> On Apr 16, 2018, at 7:00 PM, Michael Brown  wrote:
> 
> Short answer ... Yes
> 
> more verbose:
> Each board needs its own Quartus project folder.
> 
> There are 2 options:
> 
> 1.
> To create that bitfile a new quartus project targeting the DE10 Nano Board 
> with DB25 adaptor,
> needs to be added here:
> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects
> 
> With a name like:
> DE10_Nano_FB_DB25
> Based on the existing _DB25 Quartus project by Charles
> 2.
> As a last resort
> I can add a 7I76_7I76_7I76_7I76 pin file to the existing DE10_Nano_FB_Cramps 
> quartus project
> and create it with a DE10_Nano_FB name and then add something to get the 
> built in pin mux to configure for the DB25
> Also needed would be to add the SSerial core.
> (This will take some time as I'm caught up in updating and debugging my 
> synthesizer project)
> 
> 
> On Monday, 16 April 2018 20:26:39 UTC+2, mugginsac wrote:
> Michael,
> 
> I followed your instructions down to:
> 
> setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_spi.rbf
> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
> 
> It looks to me like I need something like: 
> 
> setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_DB25.rbf
> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
> 
> It looks like the socfpga_cyclone5_de10_nano_fb.dtb may already exist but 
> that I need to create the DE10_Nano_FB_DB25.rbf.
> 
> Is that right?
> 
> -- 
> website: http://www.machinekit.io  blog: 
> http://blog.machinekit.io  github: 
> https://github.com/machinekit 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Machinekit" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> machinekit+unsubscr...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/machinekit 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Short answer ... Yes

more verbose:
Each board needs its own Quartus project folder.

There are 2 options:

1.
To create that bitfile a new quartus project targeting the DE10 Nano Board 
with DB25 adaptor,
needs to be added here:
https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects

With a name like:
DE10_Nano_FB_DB25
Based on the existing _DB25 Quartus project by Charles
2.
As a last resort
I can add a 7I76_7I76_7I76_7I76 pin file to the 
existing DE10_Nano_FB_Cramps quartus project
and create it with a DE10_Nano_FB name and then add something to get the 
built in pin mux to configure for the DB25
Also needed would be to add the SSerial core.
(This will take some time as I'm caught up in updating and debugging my 
synthesizer project)


On Monday, 16 April 2018 20:26:39 UTC+2, mugginsac wrote:
>
> Michael,
>
> I followed your instructions down to:
>
> setenv bitimage 
> /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_spi.rbf
> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
>
> It looks to me like I need something like: 
>
> setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_DB25.rbf
> setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb
>
> It looks like the socfpga_cyclone5_de10_nano_fb.dtb may already exist but 
> that I need to create the DE10_Nano_FB_DB25.rbf.
>
> Is that right?
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

Michael,

I followed your instructions down to:

setenv bitimage 
/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_spi.rbf
setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb

It looks to me like I need something like: 

setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_DB25.rbf
setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb

It looks like the socfpga_cyclone5_de10_nano_fb.dtb may already exist but 
that I need to create the DE10_Nano_FB_DB25.rbf.

Is that right?

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

THe desktop image is mainly to demonstrate how responsive the kwin/lxqt 
desktop is,
and show off that Axis runs fine on the de10-Nano(with the 
de10_Nano_fb_Cramps bitfile), to put to a wider audience that local display
is a TRUE option ... :-)


This readme will get your display up and running if you follow the steps:

readme_hdmi-desktop_image.md
https://drive.google.com/open?id=1rLFGJgvm_q9CqeKDvfdKwD5T9ZRUgJaY
1.
The frame-buffer core needs to be programmed into the fpga before the 
kernel starts (from u boot).
2. 
You cannot reprogram the fpga while linux is running (the screen will go 
black). Hence the no_firmware load config example.
3.
... see below-->

On Sunday, 15 April 2018 00:10:22 UTC+2, mugginsac wrote:
>
>
> Michael,
>
> I just wrote a uSD of the desktop image with Etcher. I was able to login 
> with the console in Putty, however, I didn't see anything with the monitor 
> connected to the HDMI.
> Am I missing something?
>
>
The readme file will guide you to a working display.
 

> I am in the process of finishing the rewire of my CNC-Lathe controller 
> using a 5i25/7i76 pair. What do I have to do to load the 5i25/7i76 bit file 
> into the DE10-Nano?
>
>
Which bitfile config are you targeting for ?  (ie Quartus project)

The framebuffer core i initially only added to the Cramps flavor de10_nano 
quartus project this emulates a 5i25,
the GPIO_0 pinout is here:
Cramps2Nano.pdf 


And here:
PIN_3x24.vhd 


If you are using the db25 adaptor board:
With some persuasion it would be a reasonably small amount of work to add 
the de10 nano board with framebuffer 
somewhere around here:
DE0_Nano_SoC_DB25 

 



 

> Thanks,
> Alan
>
>
> On Friday, April 13, 2018 at 6:10:21 AM UTC-7, Michael Brown wrote:
>>
>> @Schooner and others
>>
>> OK I have now replaced the desktop image, with an enhanced version with 
>> less initial setup and updated the read me file accordingly.
>>
>> This new image uses the fw_setenv / fw_printenv functionality so the u 
>> boot variables can be set from linux (also in chroot, with some fuss...)
>>
>> Best wishes
>> Michael B.
>>
>> On Monday, 9 April 2018 12:39:55 UTC+2, Schooner wrote:
>>>
>>> Well done Michael,
>>>
>>> Just tested it and works fine on a DE0-NANO too.
>>>
>>> If you have no objections I will add them to the images at 
>>> http://deb.machinekit.io/uploads/de0-nano/
>>>
>>> Notes for anyone looking to test.
>>>
>>> Instructions are in the file readme-console-image.md
>>> DO use bmaptool to write to SD card.  dd does not seem to cope too well, 
>>> but bmap works fine.
>>>
>>> I used the console image and once the ethaddr etc was set etc. just 
>>> needed to log in;
>>> $ sudo apt update
>>> $ sudo apt install machinekit-rt-preempt machinekit socfpga-rbf
>>> and I was up and running the socfpga-stepper sim, easy as that!
>>>
>>>
>>>
>>> On 07/04/18 00:56, Michael Brown wrote:
>>>
>>> Just a FYI that I have released 2 new stretch based images that are much 
>>> more stable than the previous Jessie ones. 
>>>
>>> U-boot 2018.01,  4.9.76-ltsi-rt kernel
>>>
>>> Also one is a desktop image running LXQT with kwin and even though there 
>>> is some latency in loading, I find the windows to be much more responsive
>>> with instantainios drag around etc.
>>> And axis seems to run quite well with preview (see video demo).
>>>
>>> 
>>> https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/Release_2.0
>>>
>>>
>>> On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 

 Michael Brown has invited you to *contribute to* the following shared 
 folder:
 DE10-DE0-Nano 
 
 [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 
 



















 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]  

>>> -- 
>>> 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 machinekit+...@googlegroups.com.
>>> Visit this group at 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

Michael,

I just wrote a uSD of the desktop image with Etcher. I was able to login 
with the console in Putty, however, I didn't see anything with the monitor 
connected to the HDMI.
Am I missing something?

I am in the process of finishing the rewire of my CNC-Lathe controller 
using a 5i25/7i76 pair. What do I have to do to load the 5i25/7i76 bit file 
into the DE10-Nano?

Thanks,
Alan


On Friday, April 13, 2018 at 6:10:21 AM UTC-7, Michael Brown wrote:
>
> @Schooner and others
>
> OK I have now replaced the desktop image, with an enhanced version with 
> less initial setup and updated the read me file accordingly.
>
> This new image uses the fw_setenv / fw_printenv functionality so the u 
> boot variables can be set from linux (also in chroot, with some fuss...)
>
> Best wishes
> Michael B.
>
> On Monday, 9 April 2018 12:39:55 UTC+2, Schooner wrote:
>>
>> Well done Michael,
>>
>> Just tested it and works fine on a DE0-NANO too.
>>
>> If you have no objections I will add them to the images at 
>> http://deb.machinekit.io/uploads/de0-nano/
>>
>> Notes for anyone looking to test.
>>
>> Instructions are in the file readme-console-image.md
>> DO use bmaptool to write to SD card.  dd does not seem to cope too well, 
>> but bmap works fine.
>>
>> I used the console image and once the ethaddr etc was set etc. just 
>> needed to log in;
>> $ sudo apt update
>> $ sudo apt install machinekit-rt-preempt machinekit socfpga-rbf
>> and I was up and running the socfpga-stepper sim, easy as that!
>>
>>
>>
>> On 07/04/18 00:56, Michael Brown wrote:
>>
>> Just a FYI that I have released 2 new stretch based images that are much 
>> more stable than the previous Jessie ones. 
>>
>> U-boot 2018.01,  4.9.76-ltsi-rt kernel
>>
>> Also one is a desktop image running LXQT with kwin and even though there 
>> is some latency in loading, I find the windows to be much more responsive
>> with instantainios drag around etc.
>> And axis seems to run quite well with preview (see video demo).
>>
>> 
>> https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/Release_2.0
>>
>>
>> On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
>>>
>>> Michael Brown has invited you to *contribute to* the following shared 
>>> folder:
>>> DE10-DE0-Nano 
>>> 
>>> [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 
>>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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]  
>>>
>> -- 
>> 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 machinekit+...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Yes you can boot the images without setting the ethernet and hostname 
variables(in u boot),
however things can get a bit messy on your network as the dhcp server will 
issue a new ip address for each reboot/boot.

---

Sure for the console image (this is tested to work on both de0-nano-soc and 
DE10 nano)

I just updated the readme for The Desktop 
image(readme_hdmi-desktop_image.md)

I'm wondering if there is a way to circumvent having to add bash -c to the 
linuxcnc.desktop file (does this work on a pc ?)

I am looking into adding the fpga-load u boot variables in an easier 
fashion, so that the desktop image is just as easy to startup as the 
console one. 

On Monday, 9 April 2018 12:39:55 UTC+2, Schooner wrote:
>
> Well done Michael,
>
> Just tested it and works fine on a DE0-NANO too.
>
> If you have no objections I will add them to the images at 
> http://deb.machinekit.io/uploads/de0-nano/
>
> Notes for anyone looking to test.
>
> Instructions are in the file readme-console-image.md
> DO use bmaptool to write to SD card.  dd does not seem to cope too well, 
> but bmap works fine.
>
> I used the console image and once the ethaddr etc was set etc. just needed 
> to log in;
> $ sudo apt update
> $ sudo apt install machinekit-rt-preempt machinekit socfpga-rbf
> and I was up and running the socfpga-stepper sim, easy as that!
>
>
>
> On 07/04/18 00:56, Michael Brown wrote:
>
> Just a FYI that I have released 2 new stretch based images that are much 
> more stable than the previous Jessie ones. 
>
> U-boot 2018.01,  4.9.76-ltsi-rt kernel
>
> Also one is a desktop image running LXQT with kwin and even though there 
> is some latency in loading, I find the windows to be much more responsive
> with instantainios drag around etc.
> And axis seems to run quite well with preview (see video demo).
>
> 
> https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/Release_2.0
>
>
> On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
>>
>> Michael Brown  has invited you to *contribute to* the 
>> following shared folder:
>> DE10-DE0-Nano 
>> 
>> [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 
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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]  
>>
> -- 
> 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 machinekit+...@googlegroups.com .
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

['schoone...@btinternet.com' via Machinekit]

  
  
Well done Michael,

Just tested it and works fine on a DE0-NANO too.

If you have no objections I will add them to the images at
http://deb.machinekit.io/uploads/de0-nano/

Notes for anyone looking to test.

Instructions are in the file readme-console-image.md
DO use bmaptool to write to SD card.  dd does not seem to cope too
well, but bmap works fine.

I used the console image and once the ethaddr etc was set etc. just
needed to log in;
$ sudo apt update
$ sudo apt install machinekit-rt-preempt machinekit socfpga-rbf
and I was up and running the socfpga-stepper sim, easy as that!



On 07/04/18 00:56, Michael Brown wrote:


  Just a FYI that I have released 2 new stretch based
images that are much more stable than the previous Jessie ones.


U-boot 2018.01,  4.9.76-ltsi-rt kernel


Also one is a desktop image running LXQT with kwin and even
  though there is some latency in loading, I find the windows to
  be much more responsive
with instantainios drag around etc.
And axis seems to run quite well with preview (see video
  demo).


   
https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/Release_2.0



  On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown
  wrote:
  

  

  

  Michael Brown has invited you to contribute
  to the following shared folder:
  


  DE10-DE0-Nano
  
  DE10-SoC
  Machinekit demo image with framebuffer
  This image also works with the Atlas
  (DE0-Nano-Soc) board(tested)
  Open

  
  

  

  

  






  
  






  
  






  

  




  

  






  
  






  
  






  

  

  

  
  

  
Google
  Drive: Have all your files within reach from
  any device. 
  Google Inc. 1600 Amphitheatre Parkway,
  Mountain View, CA 94043, USA

  

  

  

  

  
  -- 
  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 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[pcwcol]

On Friday, September 1, 2017 at 7:45:40 AM UTC-7, Charles Steinkuehler 
wrote:
>
> On 9/1/2017 8:47 AM, Michael Brown wrote: 
> > 
> > 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 
>
> You're lucky. 
>
> You can easily wedge the entire system doing this. 
>
> > THis illustrates that loading/running a different bitfile / machinekit 
> > configuration will allways require a reboot when using the local soc 
> > display. 
>
> Yep. 
>
> > 1 --> It may be possible to remedy this by reloading the alt_vip_fb 
> driver 
> > (loaded as module), and resetting / restarting the x-server. ? 
>
> Possible, but quite a hassle. 
>
> > 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. 
>
> This is *SERIOUSLY* challenging and very limiting for the logic going 
> into the FPGA (placement and routing for the display driver has to be 
> locked down and can't be moved to accommodate the hm2 recompiles, this 
> also prohibits logic optimization between the partitions). 
>
> IMHO, requiring a reboot to change the FPGA configuration when it's 
> loaded by U-Boot is a minor inconvenience.  Considering the equivalent 
> with actual Mesa hardware is running the "mesaflash" utility (which 
> also requires a full power down, not just a reboot!) requiring a 
> reboot is fine. 
>
> ...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. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net 




Actually you dont need to reboot or power cycle to reload the FPGA on most 
Mesa cards, you just use the mesaflash --reload option  

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Hmmm
Easy Easy folks
IMHO it is way to late to have another either or discussion when we 
actually have it ALL.

The demo Image I have donated is fully scriped and therefore fully 
reproducable and every step / command / customisation to every step
Is in the open.
AND only addition to the default generated sd-image are the DE10_Nano 
bitfiles which not yet are merged.

THis is not an effort to compete with  RHN's bbb originated build scripts, 
but thought as an complementary alternative
with additional other feel and options.

This scripted image supports DE10 / DE0 with and without framebuffer 
out-of-the box without major issues.

By editing 1 or 2 lines in the uEnv.txt file in the /boot folder the user 
can specify:
whether to run with or without HDMI
whether to turn the screen upside down (usefull for my13" lvds screen).
And / or if to configure the fpga via u-boot or not.

The only outstanding issue is that some of the packages / kernel options 
for enabling framebuffer support, seem to prevent
the kernel from loading.

I have this issue limited to the differences in generating a Jessie 
 sd-image without or with the -desktop option
in my buildscript repo ATM. 

---
I see no need for 3-D display or opengl etc. (I prefer the 
Machinekit-client --> Machineface, Cetus)
However
I see possibilities for having an local (touch based) 2-D display of which 
the Cyclone V socs do a decent job (even without DMA which is an upcoming 
option that may improve dragging windows a bit).

---
On another note practical tests have shown that it is possible to fully 
reload the fpga, without the system going haywire (except for the blank 
screen), which indicates that linux and the built in fpga(freeze) bridged + 
the altera socfpga 4.1.22-rt-ltsi kernel play well together in a default 
non optimized for this scenario setup.

You are very welcome to test the demo image with own hands to debunk or 
verify this bold claim.

Having to physically lock down the framebuffer cores, may be to challenging 
for the small (60-70% full) DE0, however
The DE10 project uses only (28%) in the HDMI PIN_3x24_cap config, so

I cannot refrain any longer from just talking about it and have to do some 
practical real world testing going down this occult like (partial 
reconfiguration) road, and report my findings.

Intel seems to have been busy focusing on the enterprise market for now 
leaving the Cyclone V SoC as the top low-cost bid.
(I know not much about what Xilinx are doing).
THis may change as Intel now has the potential to whip up something like a 
i5-fpga with a decent 3D graphics core, when
the time gets ripe, why wait for that ?

On Friday, 1 September 2017 20:28:30 UTC+2, Charles Steinkuehler wrote:
>
> On 9/1/2017 1:11 PM, mugginsac wrote: 
> > I disagree with Charles and Schooner. I used console access for years 
> and I 
> > have had enough of it. I am tired of typing long lines of console entry 
> to 
> > avoid the conveniences of a good gui interface. There are many features 
> > available in a good gui that help avoid carpal tunnel syndrome. I think 
> the 
> > HDMI interface should be enabled by default. You can run MachineKit via 
> ssh 
> > on another machine with decent 3D acceleration but having a gui 
> interface 
> > on the DE10 still has value. If you want to talk about slow go back to a 
> > 2mHz Z-80. 
>
> You are free to work on this if you'd like.  IMHO, graphics 
> performance on the DE10 HDMI output is going to be dismal without 
> hardware acceleration, and building a GPU isn't generally a very 
> efficient way to use FPGA gates (although it is possible). 
>
> ...and I've used many single MHz 8-bit systems, most of which would 
> probably have perceptively better performance than what you can get 
> from a DE10.  But today you usually can't get by with 2 or 3 
> bit-planes of data with less than 100k pixels, or "cheats" like the 
> old character/tile based graphics displays.  And even with a fast 
> 32-bit ARM core, it takes a long time to do 3D manipulations on 
> graphics data with the CPU. 
>
> Using any sort of remote display with a built-in GPU (even my cheap 
> $20 Andriod cell phone) will give you *MUCH* better performance than 
> you could ever get natively on the DE10, even if you allocate all the 
> FPGA gates to graphics acceleration. 
>
> > You can avoid a half a billion lines of gcode by using a code generator 
> > that uses subroutines where possible instead of straight inline code. 
>
> For subtractive machining, yes.  But the really big gcode files tend 
> to be generated by 3D printing, and there isn't really an effective 
> way to make them significantly smaller. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Charles Steinkuehler]

On 9/1/2017 1:11 PM, mugginsac wrote:
> I disagree with Charles and Schooner. I used console access for years and I 
> have had enough of it. I am tired of typing long lines of console entry to 
> avoid the conveniences of a good gui interface. There are many features 
> available in a good gui that help avoid carpal tunnel syndrome. I think the 
> HDMI interface should be enabled by default. You can run MachineKit via ssh 
> on another machine with decent 3D acceleration but having a gui interface 
> on the DE10 still has value. If you want to talk about slow go back to a 
> 2mHz Z-80. 

You are free to work on this if you'd like.  IMHO, graphics
performance on the DE10 HDMI output is going to be dismal without
hardware acceleration, and building a GPU isn't generally a very
efficient way to use FPGA gates (although it is possible).

...and I've used many single MHz 8-bit systems, most of which would
probably have perceptively better performance than what you can get
from a DE10.  But today you usually can't get by with 2 or 3
bit-planes of data with less than 100k pixels, or "cheats" like the
old character/tile based graphics displays.  And even with a fast
32-bit ARM core, it takes a long time to do 3D manipulations on
graphics data with the CPU.

Using any sort of remote display with a built-in GPU (even my cheap
$20 Andriod cell phone) will give you *MUCH* better performance than
you could ever get natively on the DE10, even if you allocate all the
FPGA gates to graphics acceleration.

> You can avoid a half a billion lines of gcode by using a code generator 
> that uses subroutines where possible instead of straight inline code.

For subtractive machining, yes.  But the really big gcode files tend
to be generated by 3D printing, and there isn't really an effective
way to make them significantly smaller.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[mugginsac]

I disagree with Charles and Schooner. I used console access for years and I 
have had enough of it. I am tired of typing long lines of console entry to 
avoid the conveniences of a good gui interface. There are many features 
available in a good gui that help avoid carpal tunnel syndrome. I think the 
HDMI interface should be enabled by default. You can run MachineKit via ssh 
on another machine with decent 3D acceleration but having a gui interface 
on the DE10 still has value. If you want to talk about slow go back to a 
2mHz Z-80. 

You can avoid a half a billion lines of gcode by using a code generator 
that uses subroutines where possible instead of straight inline code.

Alan

On Friday, September 1, 2017 at 8:58:59 AM UTC-7, Charles Steinkuehler 
wrote:
>
> On 9/1/2017 10:43 AM, schoo...@btinternet.com  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=205=1046=2
>  
> > 
> > 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. 
>
> 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). 
>
> > 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. 
>
> 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. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Bas de Bruijn]

> On 1 Sep 2017, at 17:58, Charles Steinkuehler  
> wrote:
> 
> I think effort is currently better spent on things
> like fixing up the hm2_soc_ol driver and automating the uSD image
> creation.

Disclaimer: I claim ignorance on the technical side of this, and speak as a 
user.

Machinekit is mainly a motion stack, and one of the best benefits of 
machinetalk is to offload graphics/GUI.

Then if a machine runs, it hardly changes during its life imo. If it isn't 
broken, don't fix it. So I see no use case for non development setups where 
images/fpga firmware change frequently, thus a reboot is no hassle.

I agree with the above, up-to-date uSD images, like the fantastic BB images 
from RCN would be very valuable. Burn an image,  easy  install, get started 
quickly.

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Charles Steinkuehler]

On 9/1/2017 10:43 AM, schoone...@btinternet.com 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=205=1046=2
> 
> 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.

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).

> 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.

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.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[schoone...@btinternet.com]

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=205=1046=2

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.


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



--
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

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 
> cha...@steinkuehler.net  
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Robert Nelson]

On Thu, Aug 31, 2017 at 6:03 PM, mugginsac  wrote:
> Michael,
>
> How much swap did you add? I am trying to get my image to load but my SD
> writing programs don't like your image. I use  ApplePi Baker or Etcher.
> Etcher complains about no partition table. ApplePi Baker wrote an SD image
> but Linux thinks it is a CD.
>
> How do you format the uSD card??
>
> sudo sfdisk ${DISK} <<-__EOF__
> 1M,1M,0xA2,
> ---swap format goes here--
> 2M,,,*
> __EOF__

Or just use a swap file, then you don't have to worry about the
partition table..

Regards,


-- 
Robert Nelson
https://rcn-ee.com/

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Charles Steinkuehler]

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
char...@steinkuehler.net

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

THat said .. if the signature or board name check fails this should not 
cause any kernel panics requiring a reboot. 

On Thursday, 31 August 2017 23:00:08 UTC+2, Michael Brown wrote:
>
> Not that I know of the pattern has been if the signature check failed the 
> kernel would panic and talk a lot about about:
>
> unable to handle kernel null pointer dereference
>
> A google search revealed the it could be unloading some sort of variable 
> that had not been initialized.
>
> I have mostly ignored this issue until I had something more robust and the 
> phenomena may have been due to the fpga not having enough time to
> configure finish and startup before probing started (as the new designs 
> are somewhat larger, or may take longer time to initialize)
>
> On Thursday, 31 August 2017 14:37:39 UTC+2, Charles Steinkuehler wrote:
>>
>> On 8/30/2017 5:14 PM, Michael Brown wrote: 
>> > 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. 
>>
>> Yeah, this is bad and should be fixed.  Is there an issue for this in 
>> the tracker? 
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Not that I know of the pattern has been if the signature check failed the 
kernel would panic and talk a lot about about:

unable to handle kernel null pointer dereference

A google search revealed the it could be unloading some sort of variable 
that had not been initialized.

I have mostly ignored this issue until I had something more robust and the 
phenomena may have been due to the fpga not having enough time to
configure finish and startup before probing started (as the new designs are 
somewhat larger, or may take longer time to initialize)

On Thursday, 31 August 2017 14:37:39 UTC+2, Charles Steinkuehler wrote:
>
> On 8/30/2017 5:14 PM, Michael Brown wrote: 
> > 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. 
>
> Yeah, this is bad and should be fixed.  Is there an issue for this in 
> the tracker? 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Charles Steinkuehler]

On 8/30/2017 5:14 PM, Michael Brown wrote:
> 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.

Yeah, this is bad and should be fixed.  Is there an issue for this in
the tracker?

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

Yes seems like we agree :-)

On Wednesday, 30 August 2017 15:06:07 UTC+2, Charles Steinkuehler wrote:
>
> Upon further reflection, the "mandatory" uio device name should be 
> optional and have a sensible default if it's not passed on the command 
> line.  The optional device tree overlay name should not (so the driver 
> doesn't do anything with loading/unloading device tree overlays if a 
> specific overlay name isn't passed in). 
>
> On 8/30/2017 7:57 AM, 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 
> >>  
> >> 
> >> 
> >> 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=D=1=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=D=1=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  has invited you to 
> *contribute 
> >> to* the following shared folder: 
> >> DE10-DE0-Nano 
> >> < 
>  
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil=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=59a5669b>
>  
>
>  
> >> Google Drive: Have all your files within reach 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

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 
> >  
> > 
> > 
> > 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=D=1=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=D=1=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  has invited you to *contribute 
> > to* the following shared folder: 
> > DE10-DE0-Nano 
> > < 
> >>> 
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil=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=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]  
> > 
>  
> >>> 
> >>> 
> 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Charles Steinkuehler]

Upon further reflection, the "mandatory" uio device name should be
optional and have a sensible default if it's not passed on the command
line.  The optional device tree overlay name should not (so the driver
doesn't do anything with loading/unloading device tree overlays if a
specific overlay name isn't passed in).

On 8/30/2017 7:57 AM, 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 
>> 
>>
>>
>> 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
>>>  
>>> 
>>>
>>> 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
  
 
  

 ...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  has invited you to *contribute 
>> to* the following shared folder: 
>> DE10-DE0-Nano 
>> <
 https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil=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=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]  
>>
>


 -- 
 Charles Steinkuehler 
 cha...@steinkuehler.net 

>>>
>>
> 
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Charles Steinkuehler]

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 
> 
> 
> 
> 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
>>  
>> 
>>
>> 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
>>>  
>>> 
>>>  
>>>
>>> ...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  has invited you to *contribute 
> to* the following shared folder: 
> DE10-DE0-Nano 
> <
>>> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil=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=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]  
>

>>>
>>>
>>> -- 
>>> Charles Steinkuehler 
>>> cha...@steinkuehler.net 
>>>
>>
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

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 



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
>  
> 
>
> 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
>>  
>> 
>>  
>>
>> ...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  has invited you to *contribute 
>> >> to* the following shared folder: 
>> >> DE10-DE0-Nano 
>> >> <
>> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil=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=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]  
>> >> 
>> > 
>>
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

[Michael Brown]

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
 


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
>  
> 
>  
>
> ...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  has invited you to 
> *contribute 
> >> to* the following shared folder: 
> >> DE10-DE0-Nano 
> >> <
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil=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=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]  
> >> 
> > 
>
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.