>
> 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 <blaz...@gmail.com> 
>>>>> 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 
>>>>> cha...@steinkuehler.net 
>>>>>
>>>>

-- 
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 machinekit+unsubscr...@googlegroups.com.
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/dfd54122-9af8-4635-842d-e86cfe6cd757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to