> > Where did you find the (no-fw-load.ini)example where that line was Not > commeted out ?
Like I said in the first post, I started with that image. I couldn't mount the original image to check the .ini but I do see that the Git repo version is commented out. Maybe I uncommented it, not sure how I'd miss uncommenting one line and not commenting the other though.........but it happens. On Friday, June 21, 2019 at 6:27:55 AM UTC-4, Michael Brown wrote: > > I dont know how the discussion got off-list, so here's a paste: > > On Thu, Jun 20, 2019 at 6:10 PM Michael Brown write: > Ups Sorry for providing too much information, let me clarify: > You can use either: > the no load ini method (requires you setup u-boot variables to program the > fpga on boot) > OR > using a .dtbo file (device tree fragment that programs the fpga) you > specify machinekit(the hm2_soc_ol driver) to load on startup > But never both...! (as this will give problems with the uio device) > > So bottom line is If you choose to have the display option on th DE10_Nano > hdmi port: forget the .dtbo related stuff. > --- > ok ? > > > That's actually good to know. I don't think the framebuffer or at least >> the HDMI port will be necessary after I get the hardware sorted out. Do you >> know if VNC require an actual framebuffer? If I can access the desktop >> through VNC I would probably reconfigure without it when I'm done. >> > No I don't know about vnc. > > >> Now that I look at it, the reason I messed with a .dtbo file in the first >> place is because the .ini i modified contained the "CONFIG=xxx3x24.dtbo" >> line and that was throwing LinuxCNC errors until I renamed it. It's a bit >> confusing because the example FB .ini's still reference a .dtbo file is >> compiled from a .dts file that points to a non FB .rbf. >> I just commented out that config line in the .ini and MK still seems to >> load up just fine, which is probably what I should have just done in the >> beginning. Should this line be removed, or commented out from the provided >> example MK no-load .ini's? > > > Where did you find the (no-fw-load.ini)example where that line was Not > commeted out ? > > > On Thursday, 20 June 2019 23:37:42 UTC+2, justin White wrote: >> >> However can you explain to me why you think you need the .dtbo ? >>> >> >> Well actually it's because you said: >> >> The .dtbo file is compiled from the (renamed/edited).dts file via the >>> dtc (device tree compiler) tool. >> >> So if you just renamed the .dtbo file it will stil configure the fpga >>> with the "old" .rbf file. >> >> >> the "no-load.ini" (Machinekit does not load firmware on startup) method >>> masks this mistake as it requires you load your firmware via u-boot before >>> the linux kernel starts up (to not get a blank screen or worse if >>> mackinekit re-loads the firmware). >> >> >> So I thought you were saying that just renaming the .dts (plus changing >> the firmware tag) and .dtbo files was not sufficient. It does work but I am >> using the "no-load.ini" right now. I have to make some changes to the board >> and the pinouts are changing some as well so since I have to do this again >> I may as well figure out how to do it right. Are you suggesting that I >> don't need to worry about the .dtbo? >> >> On Thursday, June 20, 2019 at 4:12:49 AM UTC-4, Michael Brown wrote: >>> >>> You can just download the dtc compiler .deb from debian buster then you >>> do not have to use the -@ switch. >>> However can you explain to me why you think you need the .dtbo ? >>> >>> On Thursday, 20 June 2019 04:08:21 UTC+2, justin White wrote: >>>> >>>> Had to compile a newer version of dtc on the desktop, apparently the -@ >>>> switch isn't available until later versions. I get a .dtbo output but..... >>>> >>>> $ dtc -@ -I dts -O dtb -o DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dtbo >>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts >>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:8.29-27.19: Warning >>>> (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg or ranges >>>> property, but no unit name >>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:18.59-26.27: Warning >>>> (unit_address_format): /fragment@0/__overlay__/hm2-socfpga0@0x40000: unit >>>> name should not have leading "0x" >>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:4.20-28.11: Warning >>>> (avoid_unnecessary_addr_size): /fragment@0: unnecessary >>>> #address-cells/#size-cells without "ranges" or child "reg" property >>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:21.33-58: Warning >>>> (interrupts_property): >>>> /fragment@0/__overlay__/hm2-socfpga0@0x40000:interrupt-parent: Bad phandle >>>> >>>> >>>> Anything to worry about? >>>> >>> >>> >>>> >>>> On Wednesday, June 19, 2019 at 8:26:04 PM UTC-4, Charles Steinkuehler >>>> wrote: >>>>> >>>>> If you want to create an overlay you need to use the -@ command line >>>>> switch with dtc. >>>>> >>>>> On 6/19/2019 7:02 PM, justin White wrote: >>>>> > Any instructions on compiling the .dtbo? Trying to take some notes >>>>> on what >>>>> > I had to do to get this going and figured I'd try to do this the >>>>> right way >>>>> > but it keeps choking on the following error: >>>>> > >>>>> > machinekit@mksocfpga-nano-soc:/lib/firmware/socfpga/dtbo$ dtc -I dts >>>>> -O dtb >>>>> > -o DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dtbo >>>>> > DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts >>>>> > Error: DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:1.12-18 syntax error >>>>> > FATAL ERROR: Unable to parse input tree >>>>> > >>>>> > Same thing trying to compile it on my desktop and the DE10. Looks >>>>> like it's >>>>> > choking on "plugin" in the .dts file? >>>>> > >>>>> > >>>>> > On Sunday, June 16, 2019 at 10:14:04 PM UTC-4, justin White wrote: >>>>> >> >>>>> >> Did you mean compiled ? >>>>> >>> >>>>> >> No, I mean copied >>>>> >> >>>>> >> The .dtbo file is compiled from the (renamed/edited).dts file via >>>>> the dtc >>>>> >>> (device tree compiler) tool. >>>>> >>> So if you just renamed the .dtbo file it will stil configure the >>>>> fpga >>>>> >>> with the "old" .rbf file. >>>>> >>> >>>>> >> I couldn't find the .dtbo or .dts files so I figured I'd try this. >>>>> No >>>>> >> bullshit, it works. All of the I/O (encoders,stepgens) is where it >>>>> belongs. >>>>> >> Though if I do find the right files I'll move them. >>>>> >> >>>>> >>> the "no-load.ini" (Machinekit does not load firmware on startup) >>>>> method >>>>> >>> masks this mistake as it requires you load your firmware via >>>>> u-boot before >>>>> >>> the linux kernel starts up (to not get a blank screen or worse if >>>>> >>> mackinekit re-loads the firmware). >>>>> >>> >>>>> >> Maybe that explains it :) >>>>> >> >>>>> >> >>>>> >>> you need to change the u-boot variable bitimage: >>>>> >> >>>>> >> (assuming you copied you new (st_fpga_soc_dc1.rbf ?) bitfile to >>>>> >> /lib/firmware/socfpga) you can do: >>>>> >> sudo fw_setenv bitimage >>>>> '/lib/firmware/socfpga/st_fpga_soc_dc1.rbf' >>>>> >> sudo reboot now >>>>> >> On the soc >>>>> >> and then watch for the flashing led :-) >>>>> >> >>>>> >> >>>>> >> That's what I did, the LED flashes and I've been using it since my >>>>> last >>>>> >> post. Like you said, maybe I got away with it because of the >>>>> "no-load" >>>>> >> >>>>> >> On Sunday, June 16, 2019 at 9:27:41 PM UTC-4, Michael Brown wrote: >>>>> >>> >>>>> >>> I had some errors starting MK. I copied the 3x24.dtbo >>>>> >>>> >>>>> >>> Did you mean compiled ? >>>>> >>> >>>>> >>> >>>>> >>>> and dts and renamed it to match my config >>>>> >>>> >>>>> >>> >>>>> >>> The .dtbo file is compiled from the (renamed/edited).dts file via >>>>> the dtc >>>>> >>> (device tree compiler) tool. >>>>> >>> So if you just renamed the .dtbo file it will stil configure the >>>>> fpga >>>>> >>> with the "old" .rbf file. >>>>> >>> >>>>> >>> >>>>> >>>> and changed the firmware line in the dts to point to the new >>>>> firmware. >>>>> >>>> Then all it seems I had to do was modify the no-load.ini >>>>> >>>> >>>>> >>> >>>>> >>> the "no-load.ini" (Machinekit does not load firmware on startup) >>>>> method >>>>> >>> masks this mistake as it requires you load your firmware via >>>>> u-boot before >>>>> >>> the linux kernel starts up (to not get a blank screen or worse if >>>>> >>> mackinekit re-loads the firmware). >>>>> >>> >>>>> >>> >>>>> >>>> to point to my firmware and instantiate the proper number of >>>>> stepgens >>>>> >>>> and encoders. >>>>> >>>> >>>>> >>> >>>>> >>> --> no >>>>> >>> >>>>> >>>> Looks like a good start until I get a chance to write a proper >>>>> hal file >>>>> >>>> - >>>>> >>>> >>>>> >>> you need to change the u-boot variable bitimage: >>>>> >>> (assuming you copied you new (st_fpga_soc_dc1.rbf ?) bitfile to >>>>> >>> /lib/firmware/socfpga) you can do: >>>>> >>> >>>>> >>> sudo fw_setenv bitimage >>>>> '/lib/firmware/socfpga/st_fpga_soc_dc1.rbf' >>>>> >>> sudo reboot now >>>>> >>> On the soc >>>>> >>> and then watch for the flashing led :-) >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> On Sunday, 16 June 2019 22:24:41 UTC+2, justin White wrote: >>>>> >>>> >>>>> >>>> I renamed the files you mentioned and got an output, not sure if >>>>> the >>>>> >>>> below error means anything: >>>>> >>>> >>>>> builder@300dd4c4fceb:/work/HW/QuartusProjects/DE10_Nano_FB_Cramps$ >>>>> >>>> Inconsistency detected by ld.so: dl-close.c: 762: _dl_close: >>>>> Assertion >>>>> >>>> `map->l_init_called' failed! >>>>> >>>> >>>>> >>>> >>>>> >>>> I had some errors starting MK. I copied the 3x24.dtbo and dts and >>>>> >>>> renamed it to match my config and changed the firmware line in >>>>> the dts to >>>>> >>>> point to the new firmware. Then all it seems I had to do was >>>>> modify the >>>>> >>>> no-load.ini to point to my firmware and instantiate the proper >>>>> number of >>>>> >>>> stepgens and encoders. Looks like a good start until I get a >>>>> chance to >>>>> >>>> write a proper hal file >>>>> >>>> >>>>> >>>> >>>>> >>>> On Sunday, June 16, 2019 at 12:53:10 PM UTC-4, Michael Brown >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Looking at your errorlog this is what sticks out for me: >>>>> >>>>> >>>>> >>>>> Warning (12019): Can't analyze file -- file >>>>> >>>>> ../../hm2/config/DExx_Nano_xxx_Cramps/atlas_st_fpga_soc_dc1.sv >>>>> is >>>>> >>>>> missing >>>>> >>>>> >>>>> >>>>> So you can create a copy of a suitable atlas_3x24 .....sv named >>>>> >>>>> atlas_st_fpga_soc_dc1.sv >>>>> >>>>> < >>>>> http://www.google.com/url?q=http%3A%2F%2Fatlas_st_fpga_soc_dc1.sv&sa=D&sntz=1&usg=AFQjCNFaXzIhSaX4akk6lI9iwZh_k2ltVA> >>>>> >>>>> >>>>> >>>>> (With your naming convention), >>>>> >>>>> and customize it if you fell so inclined..... then it should >>>>> build. >>>>> >>>>> Best Wishes >>>>> >>>>> Michael Brown >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sunday, 16 June 2019 18:36:03 UTC+2, Michael Brown wrote: >>>>> >>>>>> >>>>> >>>>>> Please notice that only the header and extension is different >>>>> in the >>>>> >>>>>> two added files: >>>>> >>>>>> >>>>> >>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_3x24_cap_enc_dbspi.vhd >>>>> >>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/atlas_3x24_cap_enc_dbspi.sv >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Sunday, 16 June 2019 18:31:31 UTC+2, Michael Brown wrote: >>>>> >>>>>>> >>>>> >>>>>>> To add a new config you have to add 2 new files like in this >>>>> pending >>>>> >>>>>>> commit Charles yet has not had time to look at: >>>>> >>>>>>> >>>>> >>>>>>> >>>>> https://github.com/machinekit/mksocfpga/pull/106/commits/cf035069c539dda57131a2190499f204f9f5412f >>>>> >>>>> >>>>>>> >>>>> >>>>>>> Note that I have tried to build a cosistant (by function) file >>>>> naming >>>>> >>>>>>> convention as the names of the 2 files reflect in the bitfiles >>>>> you get out >>>>> >>>>>>> at the other end. >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> On Sunday, 16 June 2019 14:25:23 UTC+2, Charles Steinkuehler >>>>> wrote: >>>>> >>>>>>>> >>>>> >>>>>>>> It looks like the pertinent error is: >>>>> >>>>>>>> >>>>> >>>>>>>> Error (10161): Verilog HDL error at >>>>> DE10_Nano_FB_Cramps.sv(132): >>>>> >>>>>>>> object "boardtype" is not declared. Verify the object name is >>>>> >>>>>>>> correct. >>>>> >>>>>>>> If the name is correct, declare the object. File: >>>>> >>>>>>>> >>>>> /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv >>>>> >>>>>>>> Line: 132 >>>>> >>>>>>>> >>>>> >>>>>>>> I'm not quite sure what's going wrong, I haven't really >>>>> worked with >>>>> >>>>>>>> Michael's new System Verilog top-level design. >>>>> >>>>>>>> >>>>> >>>>>>>> On 6/15/2019 8:31 PM, justin White wrote: >>>>> >>>>>>>>> Trying to build the bitfile, I'm sure I'm doing something >>>>> wrong. >>>>> >>>>>>>>> >>>>> >>>>>>>>> I modified the "PIN_3x24_cap_enc.vhd" pinfile posted earlier >>>>> to >>>>> >>>>>>>> suit my >>>>> >>>>>>>>> board and tried to build it via the readme based on the >>>>> >>>>>>>>> "DE10_Nano_FB_Cramps" project. I'm sure I'm missing a step >>>>> here. >>>>> >>>>>>>> Print and >>>>> >>>>>>>>> .vhd attached. >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> On Saturday, June 15, 2019 at 2:55:03 PM UTC-4, justin White >>>>> >>>>>>>> wrote: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> No smoke yet. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> [image: Photo Jun 15, 2 47 40 PM.jpg] >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> On Tuesday, June 11, 2019 at 10:41:16 PM UTC-4, justin >>>>> White >>>>> >>>>>>>> wrote: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Well once I get a PCB all assembled I'll have to go back >>>>> through >>>>> >>>>>>>> this >>>>> >>>>>>>>>>> thread and figure out how to get the FPGA all set up lol. >>>>> The >>>>> >>>>>>>> Arduino >>>>> >>>>>>>>>>> connector on the DE10 kind of irk me, they are extended >>>>> height >>>>> >>>>>>>> an 4 or 5mm >>>>> >>>>>>>>>>> taller than the 2x20 headers so either tall pin sockets >>>>> have to >>>>> >>>>>>>> be sourced >>>>> >>>>>>>>>>> or I've thought about just desoldering the Arduino >>>>> connectors >>>>> >>>>>>>> from the DE10. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> On Tuesday, June 11, 2019 at 1:56:27 AM UTC-4, Bas de >>>>> Bruijn >>>>> >>>>>>>> wrote: >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>>> On 11 Jun 2019, at 01:25, justin White < >>>>> [email protected]> >>>>> >>>>>>>> wrote: >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Possibly, >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Need to do some testing once I get the first rev >>>>> assembled. >>>>> >>>>>>>> This >>>>> >>>>>>>>>>>> Particular board is probably a bit too expensive to make >>>>> for >>>>> >>>>>>>> the open >>>>> >>>>>>>>>>>> source world to want, and the I/O arrangement is somewhat >>>>> >>>>>>>> specific to my >>>>> >>>>>>>>>>>> needs. That many Phoenix Contact blocks gets pretty >>>>> expensive. >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> I would be interested, keep me updated! >>>>> >>>>>>>>>>>> I think machinekit can do with some additional hardware >>>>> between >>>>> >>>>>>>>>>>> controllers and wires. >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> but imo cheap is a nice to have, function and quality >>>>> come >>>>> >>>>>>>> first. Think >>>>> >>>>>>>>>>>> about how something industrial gets wired. Then you need >>>>> some >>>>> >>>>>>>> contact >>>>> >>>>>>>>>>>> blocks to easily connect wires. In the total a more >>>>> expensive >>>>> >>>>>>>> part here >>>>> >>>>>>>>>>>> will give you an edge somewhere else (manual labor). And >>>>> indeed >>>>> >>>>>>>> when you’re >>>>> >>>>>>>>>>>> a diy-er labor does not come into the equation. >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>>> I'll probably drop some OS version into the wild once I >>>>> get it >>>>> >>>>>>>> sorted, >>>>> >>>>>>>>>>>> with a more general I/O layout. This board is setup with >>>>> 6 >>>>> >>>>>>>> differential (or >>>>> >>>>>>>>>>>> single ended) encoder inputs, 6 differential stepgen >>>>> outputs, >>>>> >>>>>>>> 16 5v-30v >>>>> >>>>>>>>>>>> inputs, 24 field voltage outputs up to 500ma, 2 >>>>> opto-mosfet >>>>> >>>>>>>> outputs @2A >>>>> >>>>>>>>>>>> snubbed. Has a 5A 5v DC-DC regulator that will accept up >>>>> to >>>>> >>>>>>>> 42VDC, power >>>>> >>>>>>>>>>>> the DE10-nano through GPIO and output the spare 5v up to >>>>> 3A. My >>>>> >>>>>>>> method of >>>>> >>>>>>>>>>>> stepgen outputs and GP inputs needs some testing. >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> -- >>>>> >>>>>>>> Charles Steinkuehler >>>>> >>>>>>>> [email protected] >>>>> >>>>>>>> >>>>> >>>>>>> >>>>> > >>>>> >>>>> >>>>> -- >>>>> Charles Steinkuehler >>>>> [email protected] >>>>> >>>> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/874bf818-2778-4ae9-8a9b-c6923e1e2366%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
