> > 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/5b354432-9a1e-4331-a04b-68d4ad487942%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
