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/07edc7f3-d729-4976-8732-786738ef596d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
