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

2018-05-27 Thread 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

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

2018-05-27 Thread 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

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

2018-05-27 Thread 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

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

2018-05-27 Thread 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

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

2018-05-27 Thread 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 >>

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

2018-05-27 Thread '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

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

2018-05-27 Thread 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

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

2018-05-26 Thread 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

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

2018-05-26 Thread 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:

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

2018-05-26 Thread 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

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

2018-05-26 Thread 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

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

2018-05-25 Thread Condit Alan
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 > On May 25,

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

2018-05-25 Thread Charles Steinkuehler
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

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

2018-05-25 Thread 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

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

2018-05-25 Thread 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

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

2018-05-25 Thread 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

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

2018-05-24 Thread 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

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

2018-05-23 Thread 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

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

2018-05-23 Thread 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

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

2018-05-23 Thread 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 >

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

2018-05-22 Thread 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

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

2018-05-20 Thread 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

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

2018-05-19 Thread 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

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

2018-05-16 Thread 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

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

2018-05-14 Thread 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

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

2018-05-13 Thread 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

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

2018-05-09 Thread 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

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

2018-05-09 Thread 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

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

2018-05-08 Thread 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,

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

2018-04-17 Thread 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 >

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

2018-04-17 Thread 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

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

2018-04-16 Thread 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

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

2018-04-16 Thread 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:

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

2018-04-16 Thread 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

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

2018-04-15 Thread 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

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

2018-04-14 Thread 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

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

2018-04-13 Thread Michael Brown
@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

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

2018-04-09 Thread 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

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

2018-04-09 Thread '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

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

2017-09-01 Thread 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

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

2017-09-01 Thread 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

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

2017-09-01 Thread 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

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

2017-09-01 Thread 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

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

2017-09-01 Thread 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

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

2017-09-01 Thread 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

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

2017-09-01 Thread 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

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

2017-09-01 Thread 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

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

2017-08-31 Thread 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

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

2017-08-31 Thread 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

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

2017-08-31 Thread 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

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

2017-08-31 Thread 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

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

2017-08-31 Thread 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.

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

2017-08-30 Thread 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

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

2017-08-30 Thread 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

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

2017-08-30 Thread 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

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

2017-08-30 Thread 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)

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

2017-08-30 Thread 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,

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

2017-08-30 Thread 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

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

2017-08-29 Thread Charles Steinkuehler
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