Thank you - this means smth. is wrong with this exact BB Red unit.
2018 m. vasaris 26 d., pirmadienis 14:04:46 UTC+2, automata rašė:
>
> Hi Marius,
>
> I tried the same steps as on Alexanders website (
> https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/) on
> a Beagle bone red
On Wednesday, February 21, 2018 at 2:27:48 PM UTC+5:30, Marius Alksnys
wrote:
>
> I thought I understand at least basically all of this, as I successfully
> created such an image from your instructions, integrated it in multiple
> machines with BB Black and Green. And I used your run.py style
Sounds like a hardware issue then. Is there a default image for the BB Red
that works on your device?
To debug you can connect a UART/USB connector to the BBB so you see what
happens during boot. The debug messages are sometimes very helpful.
Another option might be to contact the element14
I thought I understand at least basically all of this, as I successfully
created such an image from your instructions, integrated it in multiple
machines with BB Black and Green. And I used your run.py style loading for
all of them.
But now it is Red and it just does not work - neither my
I tried to run different stretch images and configs on BB Red - no success.
They were working for me on BB Green and Black.
Last test is made with ready image from here:
https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/
(If you eager to start without following the steps
I tried to run different stretch images and configs on BB Red - no success.
They were working for me on BB Green and Black.
Last test is made with ready image from here:
https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/
(If you eager to start without following the steps
Here's where it starts loading the hal_bb_gpio module:
> Feb 18 12:20:36 beaglebone rtapi:0: 4:rtapi_app:17438:user hal_bb_gpio.so
> default iparms: ''
> Feb 18 12:20:36 beaglebone rtapi:0: 4:rtapi_app:17438:user halg_xinitfv:90
> HAL: initializing component 'hal_bb_gpio' type=1 arg1=0 ar
>
Hopefully with this info, someone who knows about the BBB will be
able to see what is likely happening
A SWAG from me would be that the correct device tree file is not
being used, but what do I know
;-)
On 18/02/18 12:25, Marius Alksnys
wrote:
machinekit@beaglebone:~/CRAMPS$ DEBUG=5 realtime status
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_GB.utf8)
msgd:0 stopped
rtapi:0 stopped
machinekit@beaglebone:~/CRAMPS$ DEBUG=5 realtime restart
/bin/bash: warning: setlocale: LC_ALL:
On 18/02/18 12:01, Marius Alksnys
wrote:
Line 28:
loadrt hal_bb_gpio
output_pins=816,822,823,824,825,826,914,923,925
input_pins=807,808,809,810,817,911,913
I know nothing about BBB specifically
Ok, another halrun test after trying to run that CRAMPS config:
machinekit@beaglebone:~/CRAMPS$ halrun
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_GB.utf8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_GB.utf8)
msgd:0 stopped
rtapi:0 stopped
/bin/bash:
Line 28:
loadrt hal_bb_gpio output_pins=816,822,823,824,825,826,914,923,925
input_pins=807,808,809,810,817,911,913
2018 m. vasaris 18 d., sekmadienis 13:56:18 UTC+2, Schooner rašė:
>
>
> On 18/02/18 11:37, Marius Alksnys wrote:
> >
> > CRAMPS.hal:28: insmod failed, returned -1:
>
> Whatever
On 18/02/18 11:37, Marius Alksnys wrote:
CRAMPS.hal:28: insmod failed, returned -1:
Whatever you are trying to load at line 28 of your hal file is what is
producing the error
That dangling 'DEALER' socket error sometimes shows up even in BB Black.
Don't worry about that.
Since we
I tried to run different stretch images and configs on BB Red - no success.
They were working for me on BB Green and Black.
Last test is made with ready image from here:
https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/
(If you eager to start without following the steps
Strange yes, if Marius send me news about this i reply here
Damaged hardwar is possible ?.
--
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"
Good news!
But strange, because on my side I have swap a black by a red without hassle.
Need to double check with another red I have in stock.
Frederic.
On 2018-02-03 23:10, Moi Toi wrote:
Hi
I have replaced the red fro a "standard" BBB by IGH and now start fine.
Ps : i have send the old red
Hi
I have replaced the red fro a "standard" BBB by IGH and now start fine.
Ps : i have send the old red to furaday author for debuging if other user
have the same issue.
Best regards
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
The thread here has what I'm talking about.
https://groups.google.com/d/msg/machinekit/RrNLUo4ASP4/1-Aedz5RBgAJ
I gathered from this that uboot will still run from the emmc even if you
are booting from the sd card.
This prevents that, cause it clears the emmc basically.
On Monday, January 29,
My guess is you haven't taken the steps required to enable the overlays.
Stock debian uses a different layout for the IO pins.
What this:
bash: line 0: echo: write error: No such file or directory
is likely complaining about (badly) is the pins themselves don't exist
because you haven't made
19 matches
Mail list logo
