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] >>>>>>> >>>>>> -- 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/c64b6a79-36c2-4b43-bbe9-e3ad1c0460d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
