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] <javascript:> > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/c0bb5df3-78da-478c-8ff9-c63f894c8b04%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
