>
> 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/3e37746b-343b-4736-8caf-6e7b1860b6db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
